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.
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.
Figure 2. Team Foundation Server 2010 Build Definitions
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).
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.
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.
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.
