Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

TFS2010 Build: How to access Platform/Configuration variables in a build script


The Problem: You have a Team Foundation Server 2010 Team Build that compiles a solution (.sln) with more than one Platform and Configuration.  When your build is compiling the Platform/Configuration combinations, you need to know which combination is currently being processed so that you can perform custom build logic in the workflow activities. 

The Solution: When you are inside of the “For Each Configuration in BuildSettings.PlatformConfigurations” activity in the build workflow, this information is available through the ‘platformConfiguration’ variable. 

The Discussion:

In Visual Studio, you can define multiple build configurations and platform configurations.  This is helpful for using the same code base but changing some pre-compiler variables in the code. 

image
Figure 1. The Visual Studio configuration chooser

In your TFS2010 build definition, you can choose which configuration combinations you want to compile and then the solution (.sln) will be compiled once for each configuration/platform combination.

SNAGHTML778bf11
Figure 2. Team Foundation Server 2010 Build Definitions

SNAGHTML7753623
Figure 3. Platform and Configuration information for a TFS2010 build definition

The problem I was facing yesterday was that I wanted to add some custom logic to the build script that depended on the current platform/configuration that was being compiled.  I *knew* that the build script knew which configuration it was trying to build but how to access that information programmatically wasn’t clear.

If you open up the XAML for you build script, you’ll eventually find the “Compile and Test” sequence.  Inside of that sequence is the “For Each Configuration in BuildSettings.PlatformConfigurations” loop (Figure 4). 

SNAGHTML7805a75
Figure 4. The Compile and Test sequence and the For Each Configuration… loop

If you want to find the Compile and Test sequence, open your build script XAML, and double-click the following nodes:

1. Overall Build Process
2. Run On Agent
3. Try Compile, Test, and Associate Changesets and Work Items
4. Sequence
5. Compile, Test, and Associate Changesets and Work Items
6. Try Compile and Test
7. Compile and Test

The foreach loops over the configuration combinations that you set on the Items to Build dialog (see Figure 3) and compiles the solution. 

In my build script, I’ve added some extra logic that swaps in some environment-specific configuration files (web.config, app.config) and deploys the application in to IIS

image
Figure 5. The default, out-of-the-box Compile and Test for Configuration sequence and my customized sequence

What I was doing yesterday was updating the script so that I could deploy a version of the application that runs using IIS Windows Authentication and another version of the application that runs using IIS Forms Authentication.  In order to do this, I added an “If” activity to my build workflow and set it to look for platformConfiguration.Configuration = “WindowsAuthentication”.  The platformConfiguration variable is defined by the Foreach (see Figure 4) and holds the information about which configuration is currently being compiled.  So if my configuration was “WindowsAuthentication”, I’d set up IIS to use Windows/NTLM authentication and if it wasn’t, I’d configure IIS to use Forms/Anonymous authentication. 

image
Figure 6. An If activity that uses platformConfiguration.Configuration as the Condition

-Ben

 

— Have some tricky Team Foundation Server 2010 builds that you need written?  Want some guidance on how to write your custom TFS2010 build activities?  Need help with TFS2010 and ALM process in general?  Drop us a line at info@benday.com.

SUBSCRIBE TO THE BLOG


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.