Question

I’m in the process of learning TFS2010 Team Build, Workflow and MSBuild. I’ve got a general understanding of Workflow and was recently able to do a successful test build.

Now I need some help with keeping build version and assembly versioning in sync. I’ve been reading several blogs by Jim Lamb and John Robbins on this subject however I’m feeling more confused now than when I started. Jim Lamb’s blogs talk about using a custom activity which uses the current date to set the version number and John Robbins’ blog talks about getting the last assembly version and doing everything in MSBuild since there are no extra dependencies.

Currently we are using a 4 place version number such as 3.8.0.2 then we increment the last number for each build. We use this version to synce all the assemblies. We would like to stay with this format and I’d like to handle all my versioning in workflow however I don’t know how to read the last version from an assembly that way. I’m thinking this will require writing a custom activity but what method would I use to read last version?

Thanks in advance!
Jim

Answer 1

Stuart Preston explains a simple way to set the assembly info on his blog:
http://stuartpreston.net/blog/2010/05/02/simple-assembly-versioning-with-team-build-2010/

Edit:

Above link is dead, here is the cached version:

Posted by Stuart Preston on May 2, 2010 under Team Foundation Server

There are many more sophisticated ways of achieving this but none seemed to give me exactly what I wanted, so here I present yet another way of doing assembly versioning with Team Build 2010. I wanted my Team Build number to exactly match that of my assembly versions (and not be derived), like this:

(image)

So here’s how I do it. To start off with I customise the BuildNumber format within my build definition:

(image)

In my case, I decided to customize it so that the Major and Minor version numbers “0.1” were added explicitly. This lets me control the first two parts of the version number which is what I want to achieve. I also added the macros $(Month)$(DayOfMonth) with a 1 in front of it. For the 2nd May 2010 this would generate a number 10502. (The reason I don’t use the full year here is that for today it would generate a build number of 100502 and a file version number cannot be higher than 65335).

When I decide to work on version 0.2, 0.3 or 1.0 all I have to do is increment the Build Number here and save the definition, I’m also happy to increment the number when the year changes. I said it was simple!

The final part of the build number format was left as-is (i.e. the Revision number that increments by 1 with each build on that day and resets for the next day).

Now all we need to do is retrieve this version number when MSBuild is run against the solution, split the version number and take the numeric portion into the Properties\AssemblyVersion.cs file (you will need to comment out the AssemblyFileVersion line in that file first and check it in).

Here’s the fragment that you’ll need to insert in your .csproj file (you’ll have to check it out then open it in Notepad or your favourite text editor).

<UsingTask
    TaskName="Microsoft.TeamFoundation.Build.Tasks.GetBuildProperties"
    AssemblyFile="$(MSBuildProgramFiles32)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.ProcessComponents.dll"
  Condition="' $(BuildUri) '!='  '"/>

<Target Name="BeforeBuild" Condition="' $(BuildUri) '!='  '">
  <GetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)">
    <Output TaskParameter="BuildNumber" PropertyName="BuildNumber" />
  </GetBuildProperties>

  <PropertyGroup>
    <BuildNumberSplitLocation>$([MSBuild]::Add($(BuildNumber.LastIndexOf('_')),1))</BuildNumberSplitLocation>
  </PropertyGroup>

  <ItemGroup>
    <AssemblyVersionLines Include="[assembly:AssemblyFileVersion(&quot;$(BuildNumber.Substring($(BuildNumberSplitLocation)))&quot;)]" />
  </ItemGroup>

  <Exec Command="attrib -r &quot;$(ProjectDir)\Properties\AssemblyInfo.cs&quot;" ContinueOnError="false" />
  <Message Text="Lines being added: @(AssemblyVersionLines)" Importance="high" />
  <WriteLinesToFile File="$(ProjectDir)\Properties\AssemblyInfo.cs" Lines="@(AssemblyVersionLines)" />
</Target>

(End of reference)

He modifies the csproj file to update the AssemblyInfo.cs file before build with values passed in by TFS so that the assembly is versioned according to a permutation of MMDDRev

Your situation is a bit different in that you’d like a custom build number. To do that, you could modify the BuildNumberFormat to be 3.8.0.$(Rev:.r). Since the revision is the only thing changing, TFS will automagically increment it for you.

If you ever want to update the 3.8.0. portion, you can again edit the Build Number Format manually. Otherwise you’ll need a solution for storing & parsing the build number as part of the BeforeBuild task in your csproj.