New Features in Team Build 2013 – TFS 2013

Posted by: Gouri Sohoni , on 1/3/2014, in Category VSTS & TFS (Azure DevOps)
Views: 84483
Abstract: Explore new features in Team Build 2013. Also discus how Git repository can be incorporated in Team Build and how to customize the build without changing the process template.

Visual Studio Application Lifecycle Management (ALM) allows you to manage lifecycle of the project, provides ways to manage issues and overall improves productivity. Along with various features like workitem tracking, version control and project management; Server side build is an integral part of Team Foundation Server. Using Team Build, you can create and manage build processes and use the build process to automatically test the application. You can trigger the build every time check-in is done. This is part of Continuous Integration (CI). Build can be even setup as a quality gate and only allow those check-ins to be successful if the code doesn’t break the server side build. This feature is called as Gated Check-in.

In Team Foundation Server 2013 Build, there are a lot of new features added and some old features enhanced. Today we will explore 3 of these features.

  1. Integration of Git team project
  2. Change in Build Default Template for usage of batch files or Powershell scripts in Build
  3. A new option for build output location



Integration of Git Team Project in Team Build

Team Foundation Server 2013 supports Git for version control. While creating a Team Project, we can set it to use Git repository for version control.


Once the project code is ready, committed to local Git repository and pushed into Team Project’s Git repository; we can create a Build Definition within that Team Project. To do so, select a New Build Definition option from Build as usual. We can now provide the Queue processing for the Build as Enabled, Paused or Disabled. Once the name of the Build Definition is specified and trigger selected, we can specify that the source will be selected from Git repository.


Here we can specify the Git repository name, the branch to use and if required, which branch to monitor for CI (Continuous Integration).

A separate Default Template for Git is provided


Overall Build process looks similar to the usual build process except the part which pulls the code to be built from the Git repository



Powershell scripts in Build

The second new feature that we will explore today is using batch files or Powershell scripts as part of the Build 2013. The build default process template provided with Team Foundation Server 2013 is TfvcTemplate.12.xaml

There are some differences in this process template in comparison to previous version of Team Foundation Server. In the following diagram, the templates are shown next to each other, with the TFS 2013 template shown to the right


Observe the changes in the two templates. There are some additional activities like running scripts before and after the compilation as well as before and after tests are executed. Run MSBuild is responsible for compiling on various platforms and configurations.


Publish Symbols is used to publish symbol data and the path where to publish these symbols.

We will focus on one important addition and that is to execute scripts or batch files. From the diagram below you can see how the parameters and path can be specified.


Pre-build script arguments and path are used to execute script before compilation. Post-build script arguments and path are used to execute script after compilation. These scripts can be put in the source control on Team Foundation Server.

Similar arguments and path are available for before the execution of test related assemblies and after the tests are executed.

Overall this has given a more flexible way of customizing process template. Instead of workflow customization, we can provide scripts for pre and post standard activities of compilation and testing. You can perform various tasks which need to be executed before the compilation and after the compilation, like providing version number for the assemblies.

Passing environment parameters to the script or to MSBuild

There are a number of TF_BUILD environment related variables which can be required to provide some process logic. I am noting some of them here

TF_BUILD: makes part of the script conditional

TF_BUILD_BINARIESDIRECTORY: the folder from where the build process copies files to staging location.

This folder is automatically created unless you have specified Output Location as AsConfigured mentioned as the third new feature in the beginning of this article.


SingleFolder: default setting, all binaries will be dropped at a single location

PerProject: every project or solution will have its own output location.

AsConfigured: a script can be used to copy binaries at a particular location.


We can get these variables by using the process template. We can use the GetEnvironmentVariable as the component from toolbox and configure it in xaml. The
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.BuildDefinitionName will provide the build definition name.

Observe the various values available


If we have set the output location as AsConfigured the variable data can be passed to MSBuild using MSBuild arguments

/p:DefaultPackageOutputDir=$(TF_BUILD_BINARIESDIRECTORY)\Web directory

The environment data can be passed using the scripts as mentioned earlier.


In this article, we discussed 3 new features available with Team Foundation Server 2013. We discussed how Git repository can be incorporated in Team Build. We also discussed how to customize the build without changing the process template. We can use the environment variables either by passing to MSBuild or scripts. A separate location for dropping binaries can be configured with Output Location.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Gouri is a Trainer and Consultant on Azure DevOps and Azure Development. She has an experience of three decades in software training and consulting. She is a graduate from Pune University and PGDCA from Pune University. Gouri is a Microsoft Most Valuable Professional (MVP)  - Developer Technologies (Azure DevOps), Microsoft Certified Trainer (MCT) and a Microsoft Certified Azure DevOps Engineer Expert. She has conducted over 150 corporate trainings on various Microsoft technologies. She is a speaker with Pune User Group and has conducted sessions on Azure DevOps, SQL Server Business Intelligence and Mobile Application Development. Gouri has written more than 75 articles on Azure DevOps, TFS, SQL Server Business Intelligence and SQL Azure which are published on and You can connect with her on LinkedIn.

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Can variables pass from XAML to PS script? on Thursday, June 26, 2014 3:01 PM
Very good article. I am looking at moving from 2012 to 2013 but the default template has changed so much that much of my build solution will break if I switch templates. I would like to find a way to pass my XAML variables to the powershell script so that I don't need to maintain two lists of the same variables in my build. Is there any way to do this elegantly?