The remote repo is not required if the local one should be used.

Ah, thank you so much, don't know how I missed that. :)

There shouldn't be. It's probably trying to create a new record for whatever reason and that is triggering the dupe check. There's no other provider with that name.

The "pre-release" conventions in NuGet is incredibly bizarre and changes from version to version. We do not recommend using it until they fix it. If you want all the packages to be pre-release, then you'll need to recreate all of the package files (name + nuspec file).

As an extra note, if you're upgrading agents from pre-4.0 installations to 4.X installations, it will require reinstallation. Please see the following KB article for more details: Upgrading Agents for BuildMaster 4.0

The problem with building the project with the _CopyWebApplication is that this legacy target did not copy over bin folder references if they weren't immediately referenced in the web project. The easiest way to get this to work correctly is to build the web application .csproj without checking "This is a web application project", then grab the output from the _PublishedWebsites\Project.Name\ directory - this will include any referenced libraries and be xcopied to the website's home path. We will likely change the behavior of "this is a web application project" to grab from here instead of whatever contortions it is currently doing from back in the ASP.NET 2.0 days.

In short, if you are relying on exact paths, you should use the ~\ syntax with directories (e.g. ~\Source, ~\BuildOutput, etc.) which represents an application-relative path and doesn't use any SRC or WRK directories. How the SRC and WRK directories work under the hood is as follows: The WRK directory is used as either the source or target directory if they are not both set to use their default paths. If there is a source and target path that are both set to the default, a SRC directory is used as the Source and WRK becomes the target. Before this, the contents of WRK left over from the previous action are moved into SRC in order to work with those files (you'll see "Source and Target directory same; splitting." in the logs when this happens.)

I went to the Releases table and fixed it by hand, and the sequence is correct now. Thanks.

I'm not using Windows authentication, so user rights aren't the issue. The very first thing I did was to simplify the password, and that didn't work either. I know that the connection string works, because both the web application and the service function fine. I ended up doing a manual install of 2.2.10 to get me up and running (I needed the fix for NuGet 2.8).

Hi, Thanks for the fix - I have tested in our environment and can now push with the nuget 2.8 client. Note: I did not test with the nuget 2.7 client Thanks again.

You can pull the artifact out of _PublishedWebsites, or try the "This is a Web Application" checkbox. There is a transform config file action available as well, though you can store your configuration files in buildmaster.

It sounds like the files are being marked read-only from the source checkout; I would try to use the Set File Attributes action, and set read only = off.

Ross - BuildMaster runs powershell hosted under CLR 4. To work around this, try the following: C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { <YourScriptHere> } If you have Params: Param([string]$SolutionFolder) C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { Param([string]$SolutionFolder) <YourScriptHere> } Example for SharePoint: Param([string]$Identity) C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { Param([string]$Identity) Install-SPSolution -identity $Identity -AllWebApplications -GACDeployment -Force }

You just need the BuildMaster server IP. BuildMaster agents are push-only, so only the BuildMaster service will initiate connections to agents. You shouldn't need to make any other changes to enable this.

We've added support for extensions to allow HTML issue descriptions as of 4.1.0, but we still need to update the TFS extension to indicate this. We should have it available within a day or two.

We'll be adding some options to control text encoding for the actions which create a text file in 4.1.1, but in the meantime if you want to strip out the byte order marker, it should work to add a Search/Replace File Contents action immediately after the create file action that matches only the created file. Then, enable the Use Regular Expression option and put in a Regex that will match nothing, such as ^$ The Search/Replace action should strip out the characters at the beginning of the file. Alternatively, it would be pretty straightforward to create an alternative Create File action that never writes a BOM using the script repository feature added in BuildMaster 4.1.

You may want to check v4.1; there is some improved diagnosis/debugging with agents that might give a better error message as to the issue.

This sounds like a good candidate for a Reporting Action, but with the ZippedHtml option. Although the report outputs a binary file, you could write an html file to disk with a hyperlink to the file, and use that as the index. Both would be included in the zip file, and present in the report. If the FPR file is large, it might be better to save these on disk so it's not saved in the database. There are some additional built-in reporting actions that are not on GitHub; you can find those thru Reflector or something or fill out the Source Code Request Form. There are no background actions of course, but one option could be... Trigger that watches Promotion Completed event Runs report in background; adds report to the Build using the BuildOutputs_AddOutput action Add a Promotion Requirement to verify report has completed hope that helps. I'd be curious to see what you come up with.

OK they are now triggering. Thanks. Please can you advise on how to manage the release numbers For the regression test I entered a release number one higher than the current release on the standard. In reality my regression release will never go into production. The regression Test workflow is set to a loose Automatic Release Close-Out and disabled Release Cancellation. But the standard workflow is set to strict on all these. When the standard workflow is released into production, will it cancel my regression release. Should I set the regression release to a much high number or will this screw up the standard release numbering?

Your best bet would be to do a "Delete Files (*) From ~/Src" Action.