Getting started with the TfsVersion activity
The TFSVersion activity can be used to set the version number of some or all of the assemblies being built in a TFS build. This is done without having to check files out for editing during the build process. Details of the activity can be found in the ALM Rangers Build Customisation Guide but this can be a little daunting if you are new to the TFS 2010 build process. In this example we aim to show the basic steps that are required to get the activity integrated into a build.
This document details how to set the version of DLLs, this post details how you can also use this activity to set the drop location
Before you can make use of any of the TFS community build activities you have to make sure they are available for the build system and on your development PC. Instructions for this process can be found in the ALM Rangers build guide or in the getting started page of this wiki. This page assumes the TFSVersion activity is available in the developers build process workflow toolbox. Hence we are able to build the workflow shown below
The first step is find the Get Workspace activity in your build process, this is where the files are pulled from the TFS server to the local build agents workspace. After this activity add a FindMachingFiles activity (from the Team Foundation Build Activities tab in the toolbox). In the workflow above it has the display DisplayName of “Find the AssemblyInfo files”. As the name suggests this activity is used to find all the assemblyinfo.cs files in the build we will be editing.
The result of this find is stored in a workflow variable FilesToVersion. This should to be created with a type of IEnumerable; it’s scope, in the default workflow, was set to Initialize workspace. Once the variable was created the activities output can be assigned to it
It is useful to list the files that will be versioned in the build log. To do this add a ForEach activity (from control flow tab in toolbox) that returns each file name (string) in the FileToVersion collection variable and logs them via a WriteBuildMessage (from the Team Foundation Build Activities tab in the toolbox). This is set to High importance to make sure it appears in the log.
Next add the TFSVersion activity (from whichever tab it was added to in toolbox). This has to have a few properties set else it will not work. If they are not set it may give strange errors, usually relating to null objects as it tries to slice up strings to generate numbers.
Prior to editing the activity’s properties another variable is needed, this time a string called VersionNumber. This is used to return the TFSVersion activity generated version number for logging. Also needed are two In direction string workflow arguments called Major and Minor. These are used to pass the values needed for the generation of the version number, in the sample they are used to generate a version number in the format
[Major].[Minor].[Elapsed days since StartDate property].[number of builds run today] e.g: 4.5.229.3
The StartDate property will default to the date you create your new build definition. You can also provide an argument to all the setting of this to better control the third value. A gotcha here is that this property is a DateTime value so if you enter '1 Jan 2012 11:00' the third value will increment at 11am not at midnight as you might expect if you thought it was a simple date
For more details on the other properties and options in this activity see the ALM Rangers build customisation documentation
Finally add another WriteBuildMessage to log out the generated version number
Save the edited build process template and create a build using it. Set all the usual parameters, and the Major and Minor number to the values required for the build, in the example 4 and 5
When the build runs it should show the generated version number in the log and the built assemblies should have the version details expected.
