A small guide to editing your TFS 2012 build templates

TFS 2010 and later versions use Workflows (WF) at the core of their mechanics. Workflows are intuitive to edit, and powerful as any high level scripting language can be. However, in the context of Team Foundation Build, they need a particular set up with Visual Studio if you want a smooth editing experience. This post will hopefully help you in setting up a cohesive environment in order to edit your build process templates. This is just a proposal, this is the way I prefer setting it up, feel free to keep whatever you want here.

Team Project organization

I advise to use a “test” Team Project and edit your templates there. Why?

  • Test your build in the test Team Project and when it’s operational, copy the file(s) into your production Team Project. You don’t mess with a renamed or temporary template , nor produce unwanted changeset noise in the production Team Project. Very simple.
  • Because you may need to use another build controller, but we’ll discuss that later.

So we’ll need a Visual Studio solution and project in order to edit the Xaml template properly. Where shall we store that Solution?

Solution setup

Answer: not far from the build process templates : in a subfolder!


All you need actually is a regular class library project, target Framework 4.5 for TFS 2012 builds:


Notice there is no Xaml file at the project level, this is because they are added into the project « As Links », directly from the parent folder :


You can distinguish linked files from other in your projects because a of the tiny arrow on their file icon:


When I checkout the the Xaml template file, it is checked-out from its original location, this is fine.

We want to use a project for multiple reasons :

  • Compiling will help us to removing errors in the workflow file and it checks the references
  • It is necessary if you have custom assemblies, and frankly, you *will* have some at some stage. If you don’t go grab the latest Community TFS Build Extensions and you’ll have *very* helpful activities for your builds
  • We want “drag and drop” editing, if we have custom assemblies, this is the best way to do it

In order to compile nicely, you’ll need to add several references, this is where it gets not that obvious, nearly tedious, but you’ll need to do this only once in your life, so that’s ok 😉

References setup


Some of the are not easy to locate, here they are:

  • Microsoft.TeamFoundation.TestImpact.BuildIntegration : %ProgramFiles%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.TestImpact.BuildIntegration.dll
  • Microsoft.TeamFoundation.TestImpact.Client : %windir%\assembly\GAC_MSIL\Microsoft.TeamFoundation.TestImpact.Client\\Microsoft.TeamFoundation.TestImpact.Client.dll (this is bad, we should *never* *ever* have to reference something in the GAC, hope this will be solved in next version)

Now you can edit the worfklow and compile it.


The development cycle of builds (aka the everyday life of the build master) consists in:

  • Check-out the workflow template file
  • Modify the workflow file
  • Check-in the worfklow file
  • Launch a build that you have set up with *this* workflow file

Adding custom assemblies

We are now set up for throwing in some custom assemblies. First, add the assemblies (and their associated .pdb) in an “Assemblies” folder, create it if necessary, just under the BuildProcessTemplates folder. What is important here is that this folder is configured in the properties of your Team Project build controller (Builds -> Actions -> Manage Build controllers…)


I’ve added my custom activities assemblies and their dependencies, and the Community TFS Build Extensions assemblies:


Simply add the assemblies that contain the activities you’ll need as regular references in your class library project. For a starter you’ll want TfsBuildExtensions.Activities.dll. I also added my custom activities library (no need to reference the dependencies).

The need for a separate build controller

If you are serious with builds (if you have many production builds you can’t afford to interrupt for with your developments), you’ll want a separate build controller. It is easy to deploy.

When you check-in some assemblies in the custom assemblies folder, the build controller restarts, and cancels the builds in progress. This is where it gets handy to have a separate controller for testing purposes. And be aware of your production build deployment timing.

NB : checking-in the Xaml files does not restart the controller.

Toolbox setup

In order to drag and drop custom activities from the Toolbox, you can do the following:

  • Create a new Tab in the Toolbox
  • “Choose items” and browse up to the assembly that contains the activities you want
  • They now appear in the Toolbox, you can drag them into your build workflows

Without the project references to the corresponding assemblies, drag and drop would not work…

Finally, all is set up, you should be able to edit your builds the easy way. Enjoy! Smile

Leave a Reply

Your email address will not be published. Required fields are marked *