Thanks for the report - I'll have a dev take a look at this and fix it for the next version, which should hopefully be out today (8/14/14).

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.

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.

It's unlikely this will be supported. There is no way to identify from metadata a symbol package vs a regular package... you have to open the zip file and see if it contains pdb/src files... which means we'd have to download every version of every package in a remote feed. If Microsoft / NuGet team ever implements a mechanism for identifying , then it's a possibility.

Thanks - somehow I missed that in the docs before. I will add this as an open issue (PG-221).

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.

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])

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

As of 3.1: Active Directory / LDAP Integration Filter Packages by Name & License Load Balancing & High Availability Granular Privileges & Security

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.

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

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.

We can add a configurable throttle to the timer that triggers a package rescan. In the meantime, you can always trigger an immediate index rebuild by either setting the RebuildPackageIndex setting (under Admin->All Settings) to True, or by restarting the ProGet service.

At some point, the NuGet client started requesting every package version instead of just the latest for updates. The only way to fix this on our end is to add paging/result limiting for feed output. We could hack in a configurable result limit pretty easily which should fix this for you in a maintenance release.

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!

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

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.