Build Controllers and Build Agents

December 1, 2008

New for Team Builds in Team Foundation Server 2010 is the concept of Build Controllers. In the previous versions of Team Foundation Server (2005/2008), you were only able to assign a Team Build to a specific Build Agent. This means that when the Build Agent is offline or in failure, your Team Build won’t run and you will have to manually switch to another Build Agent.

In Visual Studio Team System 2010 you must assign the execution of a Team Build to a specific Build Controller instead of a Build Agent. The Build Controller will now be responsible for managing a custom pool of Build Agents and will select the rightBuild Agent to run the Team Build. In the screenshot below you can see that the Default Controller has a pool of 2 Build Agents : Default Agent and Pieter’s Agent. A Build Controller – like the Build Agent – may have 4 different states : Enabled, Disabled, Unreachable and Initializing.

New is also the tagging system for Build Agents. You may for example tag a Build Agent as a WinServer2008 machine or as VeryPowerful.

These tags may be used during the configuration of your Team Build. When a Team Build needs to run on a Windows Server 2008 machine, you can enforce this in the Build Process setup on the ReservationSpec of the agentScopeActivity [“Select an Agent and Build”].

When preparing a demo for my VISUG session last week, I noticed that on the VS2010CTP (October 2008 Release) there’s only one Build Agent assigned to the Default Build Controller and I couldn’t find a way to assign an extra Build Agent to the Default Build Controller. Brian Harry forwarded my question to Jim Lamb and Aaron Hallberg of the Team Build and they finally came up with the magic : for now it’s not possible to do it via the user interface, but for now you need a command line to do it …

  agent /new /name:"Pieter's Agent"
  /BuildController:"Default Controller"

This exe runs in the Team Build Folder of %Program Files%\Microsoft Visual Studio v10.0 Team Foundation Server. After executing this command, an extra TFS Build Agent should pop up in your Task Manager …

Source Server for TFS Builds

October 23, 2008

This is not yet a widely known practice in the field, but setting up a Source Server for TFS Builds in an enterprise development environment can be extremely valuable.

My friend and ex-colleague Jelle Druyts wrote a few months ago an excellent blog post about how to set up a Source Server for TFS Builds.

Anyone who will reference assemblies that are built with a source server enabled TFS Build will be able to debug those assemblies in the original source code … great for framework code for instance!

When an assembly is “source server-enabled”, the pdb file will contain the full path and the exact version of the file in source control that was used to build that assembly. If the debugger then enters a method, Visual Studio automatically downloads that correct file, places it in a local cache, and opens it for debugging. This is super sweet!

If you follow the guidelines of Jelle, you need to add the custom target RunSourceServerIndexing somewhere in your Team Build script, but he doesn’t specify exactly where you need to include this.

Well, you have two options : you can do this in your TFSBuild.proj file or you can also put this custom target in an underlying .targets file to make it more reusable. The TFSBuild.proj file is the easiest option, but I would recommend an underlying .targets file. In fact it’s always a good practice to make an underlying .targets file for all your common Team Builds. The idea is to make your .proj file as clean as possible and put all the logic and commands in an underlying .targets file.

In the image above you can see that I’ve created a specific target for all Compuware Team Builds on the Build Server. This .targets file must be imported in all TFSBuild.proj files and to enable source server for my Team Builds, I’ll just need to create a boolean variable in my TFSBuild.proj and pass it to the Compuware.targets file.

The Compuware.targets file will do all the required steps in the background. Note that the default is set to false for the variable SourceServerIndexing.

If you follow this pattern for other build tasks, you will end up with a clean TFSBuild.proj file and you will only need to pass booleans (and/or other variables) to the underlying .targets file that will contain all the reusable build tasks. Note that automatically all TFSBuild.proj files will import the default Microsoft.TeamFoundation.Build.targets file. Make sure that you never edit this master file, because it may jeopardize the working of your Team Builds when you need to migrate to another version of MSBuild.

Another small issue I came across when following the guidelines : the location where to drop the TFIndex.cmd file may be different than pointed out in the document (due to a different default location of the Debugging Tools). If that’s the case you must also check the location of this file when you set the custom target RunSourceServerIndexing.

If you haven’t taken the time to explore the possibilites of a Source Server for your TFS Builds, please do so now! You won’t regret!

No code coverage result with Team Build?

October 10, 2008

When creating a new Team Build with the Build Wizard in TFS 2008, it may be possible that you won’t have code coverage results while you have this option enabled in your testrun configuration file. This depends on how you selected your tests to run …

  1. If you have chosen to run tests that are listed in a Test List, then there won’t be any problem : code coverage results will be available because all testrun configuration settings will be picked up in the testrun configuration file via the .vsmdi file.
  2. If you have chosen to run tests with the TestContainer option, then the testrun configuration file is not picked up because there won’t be any trace of a .vsmdi file in your build project file. You may fix this by manually adding the following line to your .proj file.


    This line (to be added in PropertyGroup of .proj file) will pick up the test run configuration file and will control the way tests are run.