I'm afraid we don't have that tutorial yet; but we'd like to soon!

In short, don't use the wizard, we have decided to remove them in v5 anyway because of problems like this. Instead, simply create a Standard Application, and then visit the Workflows tab, and add a Build Step that imports from TFS. That's actually all the wizard is supposed to do anyway.

That's great news ! Thank you for following up :)

i have 2015 team explored installed but not succeeded in same schenario.

Hi Damian, I completely that you shouldn't have to install a client to use TFS. Unfortunately, only the most recently (v2015) libraries are licensed for redistribution, and these libraries require .NET 4.5, whereas BuildMaster v4 only requires .NET 4.0. These libraries also don't seem to connect to earlier versions of TFS unless VS2015 was actually installed; it's a bit frustrating for us, and other ISVs as you can imagine. We have requested a redistribution license of the earlier libraries, and we can continue to explore getting it to work on our end, but it's not at all trivial. The currently solution is to GAC the assemblies yourself or to install the TeamExplorer 2013 client, which does GAC these assemblies.

So I wanted to respond on here, I wasn't quite sure what to do with the information but I wanted to proceed. What I did was the following: Forked the GitHub repository Modified the TfsBuildActionEditor to have a Checkbox for [Validate Build Status] Modified the TfsBuildAction to use this and created a ValidateBuild function If the Check is selected it sends an error and pulls the Build Errors from the Build Details and displays them. I am not sure if this is something you wished to add so I did not submit a pull request. I could do so, but this can be considered answered. The whole point being that we didn't believe that "Create TFS Build" goal was met during a build failure, and there should be a way of validating that this actually did occur. If a build controller fails then a build was not created, or was partially created, and thus the Action needed to be able to reflect that. This also helps keep the CI running smoothly since it now becomes very apparent why a build broke and does not actually break test. Hope this helps anyone else who hits that! Consider this closed.

Please see the TFS extension for information on how to do this.

It's not recommended to check-in the modified assemblyinfo.cs file. For a few reasons, including the one you identified: it causes issues with source control related to the build. But moreover, attributes in AssemblyInfo.cs are metadata more than code; in other platforms (like Java) these are always added as part of the build process.

This error is coming from nuget.exe; depending on the version of nuget.exe you're using, AD / integrated authentication simply will not work. It's supposedly fixed in 2.8.2, but some users say it doesn't work in 2.8.3. It's pretty broken in 2.8.1 and 2.8.0. Although it sometimes works in 2.7. The 2.6's seem to be fine, for the most part. ProGet.exe, from the now-defunct client tools, of course will work fine, or a simple HTTP PUT operation.

When you say, "TFS build gets the Source and builds all in one step" ---- do you mean there's a single action (like an MSBuild script) that gets source and builds? If so, then you'll need to make a parameter to this script, and have that update the build/release number with the approraite buildmaster variables.

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.

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.

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.

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 main strategy is to have one application per website, and then either: Pull the core 30 projects and build them as part of each website application, you can use shared/linked action groups for this to make it a little easier. -or- Build the web core files in their own application as you've started to do it seems, and store the build output as an artifact, then import that deployable in each of your website applications. This allows you to deploy the artifact with the core files in it before you build one of your web applications. We've named this option the "Core Version" pattern, and you can find a specific example of it here: http://inedo.com/specifics/buildmaster-extensions I will also note that deployment plans are getting a nice overhaul in the upcoming BuildMaster v4.3, it will be much simpler to share deployment plans across applications so managing plans for this scenario will be even easier.

Thanks for the additional information. I've logged this as an item in TFS (https://github.com/Inedo/bmx-tfs2012/issues/16), and we'll fix it ASAP. In the mean time, it might be easy to work-around with doing a clone/patch: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension.

Hi Tod, We upgraded from an older version, 3.6 to 4.3.8. The feature "Update Checklist" is a nice one and at the moment "all green". Execpt for one issue, the "Test your deployment plans". On our server we are running TFS 2010, version 10.0.30319.317. In Buildmaster we added the TFS2012 extension. Regarding your last remark "connections to TFS are now made by the BuildMaster service instead of the web application", do you mean by this that the "service-user"should have acces now to TFS ? Kind regards Martin

No, the URL triggered builds are designed to be "fire and forget". However, even without a quiet period, the builds are still queued in a sense that they will not run over the top of themselves until the previous one is completed.

I know this is a really really old thread but I thought I would share something that we did for our continuous integration builds / deployment process. Every build drop location for each build definition will contain a "Latest" folder in addition to the "versioned" folders that contains the output of each build. At the end of our build template, we perform the standard activity of placing the build artifacts in the versioned dropped location. For SUCCESSFUL builds, we copy the contents of the drop location and update the "Latest" folder. If a build fails for some reason, we leave the contents of the Latest folder alone. Our nightly automated package and deployment processes (for automated integration testing) have been simplified to always pull from the "Latest" folder. They can determine if the folder contains the same version as the last one or if it's been updated.