Yes, this is a bug. We've been able to reproduce and fix it. The fix will be included in the next BuildMaster release, but if you would like a SQL patch to run sooner, you can email support at inedo.com and we'll send it to you.

For reference, I have logged this issue as BM-1636, it should likely be included in the v4.4.7 maintenance release.

This question was resolved via other means, but the solution would be to upgrade to v4.5+ of the Azure extension.

You can add "Auto-promote to next environment" as a Post-Deployment step for your build step, and then the build will automatically be deployed to integration once the build step completes successfully and all promotion requirements are met (i.e. approvals, and automated requirements).

Turns out that a default Win7 install (chosen to keep parity with our dev environment) has power saving enabled. Disabling sleep seems to have solved the problem. I am not a smart man...

Generally, load errors are logged to the BuildMaster error log within the software. You could also get live log messages by following this article. Periods in the assembly/file name are allowed, so that must have been unrelated. It's also worth double-checking the extension overview page which will show the load errors, but they don't immediately jump out: [image: EDJnd0T.png] For additional troubleshooting with regard to extension loading: make sure to restart both the BuildMaster Windows service and web application service or IIS application pool once the file is added to the Extensions path make sure there is a BuildMasterAssemblyAttribute specified in the project (normally in AssemblyInfo.cs) the project is targeting the v4.0 or v4.5 version of the .NET framework the file name, the assembly name, and the containing .bmx file all match (i.e. "CustomExtension.dll" should have the assembly name "CustomExtension" and must be contained in the zip file "CustomExtension.bmx")

There isn't a built-in predicate for this at this time, so you'd need a custom one.

Yes, you can use Linked Action groups for this, or even share the entire deployment plan and use a variable server for the action groups. Then the actions can inherit the server from the parent action group.

This is separate issue altogether, but it seems to be related to something locking the working directories that Perforce is trying to use.

This has been fixed in v4.4.4

Thank you for your help!

Application-level variables take precedence over server variables. Also note the "Legacy variable support" setting under the application's settings, it may be configured to not accept %VAR% as the variable syntax.

I can't seem to reproduce this. I've added both an action that simply runs a script and another action that runs a Script Repository script, and both of them write to the output log using write-output. If you're using the "Execution PowerShell Script" action, did you make sure to check the "Log Output" option? Can you export the deployment plan of a simple application that demonstrates this behavior?

Fixed! This is included in v4.6 of the NuGet extension, which is now available.

If the projects are located under a different root, it's easiest just to use multiple Get Latest actions if you don't want to get the entire root in one action.

Good questions, take a look at the Upgrade Notes for each minor version from 4.0 to 4.4, this will detail any breaking changes, but those are generally related to SDK and API use. If you have not developed your own personal custom extension, then you can ignore the SDK breaking changes. To make a backup of all BuildMaster settings, simply backup the BuildMaster SQL Server database. The installer should give you the option to do that as well provided the software is installed on the same server that hosts the database.

I'm not sure the component we use to FTP supports negated wildcards, but you can simply add a Delete Files action before this that operates on *.config Alternatively (if you don't want to delete because you may re-use the files), you can use the Synchronize/Transfer Files action to a temporary directory (e.g. ~\Ftp) and use a !*.config mask on that to not transfer the configs, then use the FTP action from ~\Ftp as the source directory.

That action will package and deploy in much the same way as Visual Studio does when you click "Publish" for the solution, so it should only include the correct transformed configuration based on the publish profile selected.

Yes, SQL Server 2014 is supported - I will update that article.

I figured it out. In the setup screen, the "TFS Server Name" instructions do not specify that a project collection needs to be included in the URL. Once I added the project collection name to the end of the example URL given on the setup screen I was able to connect.