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.

ProGet does not support being installed in a virtual directory; it must be at the site root.

We have upgraded to Buildmaster 4.0.9 (B31) and the "Execution Status" == succeeded work better but still not correctly. The predicate test is on the Action Group which contains 2 separate actions. The first action fails (and shows as failed in the log) then the next action succeeds and this marks the Execution Status as succeeded again to the remaining predicate tests pass. It would seem that the Execution Status should not be set the succeeded after it has been set to Failed.

Additionally, if you have publish profiles saved in your solution, you can add the following additional argument that will exhibit the same behavior as AutoParameterizationWebConfigConnectionStrings=false for the chosen ProfileName: /p:PublishProfile=ProfileName

The "default" folder (usually the SRC subfolder) is unique to applications and deployables, and is housed under the <bmas-tmp>\A<appid>\S<depid> folders. It is cleared during the "preparing agents" step at the start of every action, unless it's a re-execution of a failed deployment. Only one execution within an application is permitted at the same time, so the second one created will be queued until the first completes.

Yes; if there is no deployable, then "0" is used as part of the path (e.g. <tmp>\A12\S0\WRK\my-path)

It's not available now, but we are strongly considering targeting that (and some related features) in v4.2, which should ship in March.

It appears the user that is running the web application does not have the needed permissions to restart the BuildMaster service. If you either 1) change the user account to one that has permissions to do so, or 2) manually restart the BuildMaster service, you should see the extensions.