This project is read-only.

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 the basic steps that are required to get the activity integrated into a build.

Before you can make use of any of the TFS 2010 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 StyleCop 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


Step 1 – Getting the files

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<string>; 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


Step 2 – a bit of logging

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.


Step 3 – the actual versioning

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]


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



Step 4 – the log the version number

Finally add another WriteBuildMessage to log out the generated version number


Running the build

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.


Last edited Jul 22, 2012 at 9:58 AM by rfennell, version 5


utekai Dec 17, 2013 at 6:44 PM 
Worked fine. Using the settings in the TFSVersion activity able to easily set file version as well as assembly version. The only difficulty of the overall implementation is in setting up to edit the workflow and getting the workflow accepted by the build. Once that's in place the rest is relatively easy and works consistently. We're using TFS 2012, but develop on VS 2012 and 2013. Though I started out editing the workflow in VS2013, dll conflicts caused a move to VS 2012, and I'd not recommend mismatching the VS and TFS versions (for instance editing the workflow using VS 2013 and then building on TFS 2012), rather I'd recommend only using 2013 versions or 2012 versions for both VS and TFS. Thumbs up for the overall TFS Build Extensions project here on codeplex, it's a definite value-adder for us.

MohsenMahdieh Mar 13, 2013 at 7:13 AM 
It is great. Something is not clarified to me. As you have shown in your screenshot, it updates both file version and product version to
But you haven't set SetAssemblyVersion to true. It means we don't expect to get product version set to version created by this activity..
How could we change the behavior to just set file version to and set product version to

choucchouj Feb 19, 2013 at 1:16 AM 
the default rules for C++(not MC++) as a standard?
if I use C++(not MC++),how can i use the TFSVersion activity?

jessehouwing Apr 10, 2012 at 8:39 PM 
Ohh and the default rules for VB.NET, MC++, C# and Wix as a standard :)

jessehouwing Apr 10, 2012 at 8:38 PM 
@Ed, Thanx! I'd like it even better if this thing were extensible. I'm thinking of a filespec to select the files to update, an type (Xpath a Regex), an expression to find the nodes/lines to update. Then an Action which is either SetVersion or SetGuid. Then a Value which is either something fixed or a macro. That seems to cover all my needs :). All of this through the Build Definition Process UI. And then probably make only the VersionToSet editable from the Queue Build screen...

EdBlankenship Mar 8, 2012 at 12:50 AM 
@Jesse H. That's a super good idea for updating WiX projects automatically.

jessehouwing Mar 7, 2012 at 9:50 PM 
Would be nice if TFSVersion would also be able to update Wix project files with a new version number and a new Guid for the ProductID.

magges Dec 9, 2011 at 12:20 PM 
How can I only stamp the version to Projekct that has been changed?

rfennell Sep 26, 2011 at 7:45 PM 
If you want to sync the build number and the version number you can try the technique described here

ted_beck Aug 22, 2011 at 3:30 PM 

This is great but is there a setting to update the drop folder with the version output? It would be nice to have a format such as 'TeamBuildProjectName_Version'