Yes, I believe that does make sense. If I want to be able to control order of execution, it sounds like I should turn my deployables into their own separate child applications. Then I can specify order of deployment of each child application within whatever "master" application I am deploying.

The XML you have: <ReleaseDeployables><ReleaseDeployables> should be <ReleaseDeployables><ReleaseDeployable> (notice the missing s on the inner element).

Can you verify that: the TFS services are accessible over port 80 there is no firewall blocking that port access to the root path is open (e.g. /tfs, you can test this by trying http://windows2012r2-1/tfs/DefaultCollection instead [or whatever collection name you're looking for])

In .net, it's usually best to split out your web.config files into multiple files using the configSource option. So, <appSettings configSource="web_appSEttings.config" /> This way, you only need to edit web_appSettings.config when a key changes.

The 0.0 release is merely a setup release, the number for that cannot be set. However, you can cancel that release and simply create a new one and enter in 1.0 for its release number.

Can you be more specific? What do you mean by, "entire database"? The built-in Change Scripts feature will allow you to script an entire database if needed, and ensure change scripts get run once and only once.

Thanks Andy ..server restart did the trick...cheers!!

It's possible via IIS / appcmd, but the BuildMaster action does not support this behavior.

Thank you Steve. i have figured it out. it was downloading the code in different path. Thanks Again

Predicates in combination with variables (e.g. the Set Variable Value action, $BackupDB = true, then check for that later as necessary) are a good idea for the meantime. We've had requests that imported deployables should be allowed to be dependencies and that feature is scheduled for a future version.

Thanks for the bug reports. This renaming bug will be fixed in the next release. It's only a SQL/stored proc change, so if you would like a patch to fix it against your DB, we can send it to you. We've also fixed the broken link and that will be updated on our next website push. Thanks for letting us know!

You can watch the service logs (Admin > service) to see how this "rouge" build is being created. The Scm Watcher will identify how it's specifically searching for changes, and what's causing the trigger to fire.

Issue #21 opened in Github. Thanks for the comments!

Oddly, running the service in interactive mode seems to have solved the problem: the deployment is now complete. I didn't do anything but stop the service and start it interactively, and I didn't notice anything unusual in the output. It did look like it found the action and ran it, as far as I can tell, but didn't say what had been in the way.

This is a known issue (BM-1546) for BuildMaster v4.3.8 and will be resolved in v4.3.9.

You could try calling the stored procedure directly via the SQL API: DECLARE @B VARBINARY(MAX) SET @B = CAST('yourname' AS VARBINARY) SET CONTEXT_INFO @B EXEC Applications_PurgeApplicationData @Application_Id or view it in SSMS to see the actual SQL.

Were there any error messages before this happened? Either way, I would restart the BuildMaster service and web application. It also may be worth upgrading to the newest version to see if that helps.

You can also get this error if you do not supply a valid private key passphrase for the private key.

Only the single agent port is required to be open. As a workaround, if you have BuildMaster database access, you can just set the status of the particular server to FORCE. If you have a custom extension, you could write a quick custom recipe that can do it as well - just implement the IServerRecipe interface for a RecipeBase object. You can find out how this works in the Creating an Auto-Deploying Custom Extension Application tutorial which contains a downloadable example project containing example recipe code.

You'd have to disable the custom errors in all settings, but regardless, we believe the problem was that the clone procedure would fail if the database user did not have ALTER permissions on a certain table (don't worry, we weren't doing anything crazy -- just an identity insert). We've reworked them so that this is no longer a requirement. We'll have a maintenance release out today that should resolve it.