Project Description
This project provides a custom activity for TFS 2010 build workflows which can be used to implement assembly versioning. Unlike many similar projects, it is especially suitable for SharePoint codebases since the default setting increments the 'assembly file version' only, leaving the main assembly version at 1.0.0.0.
This is preferred in SharePoint development, since the need to maintain assembly references or binding redirects is eliminated with this approach.
* Note: currently only C# projects are supported. I'll extend if there's demand for other languages. *
Overview
Since TFS2010 Build does not provide a simple switch to enable assembly versioning, some customization of the build process is required. The activity in this project allows you to specify whether you wish to increment the main assembly version, the assembly file version, or both.
This solution sets the assembly version to the build number auto-generated by TFS for each build - this is configurable, but the default is “<build name>_<date in reverse format>.<auto-incrementing revision number>”. Specifying which version number should be used can be done in the build process definition:
To use, the XAML workflow definition for your build process must be edited, and the custom activity dropped in:
When a build executes, you should then see an entry in the build report showing each assembly being versioned:
And at the end, you can easily see the version of an assembly by right-clicking and going to its properties. In the example below, I've versioned just the assembly file version only and because I'm using a string in the build number, it comes out in the product version attribute (N.B. this is just how .Net assembly versioning behaves - if there's no string it goes into the assembly file version):
