Eric's Blog

Day to day experience in .NET
Welcome to Blogs @ IRM Sign in | Join | Help
 Search

Disclaimer

The content of this site is my own personal opinion and does not in any way represent my employer, it's subsideries or affiliates. These postings are provided "AS IS" with no warranties, and confer no rights.

This Blog

Assembly Versioning in a TFS Team Build

There are plenty of post about how to set a custom assembly version in a TFS Team Build, but since I ended up choosing an approach that was a mix of the others, I thought I could just as well blog about it too. This post will hopefully be followed of another post about doing ClickOnce publishing in the TFS Team Build too and I will use the same version in there too.

Lets start with a look at the result I wanted to achieve. The last two items in the Build Explorer are the standard name of builds in Team System 2010, but as seen in the top three I have a custom name which is based on the version number. The drop folders have the same name as the build and the name is also used for labeling (which is default). All built assemblies in the drop folder have the File Version set to the corresponding version number.

These are the steps I did to achieve this result:

  1. First of all I prepared the solution so that it has a single file for all projects that contains the version number (and some of the other attributes from AssemblyVersion.cs) and I called the shared file SolutionInfo.cs. This is a common trick to make it easier to have all projects share the same version numbers and there are plenty of posts covering the details, for example this one.
  2. In Community TFS Build Extensions there are custom build activities for working with version numbers. To be able to use it in my builds I first downloaded it and added all of the assemblies in a new folder under BuildProcessTemplates.

  3. With this in place it is time to customize the build template. I took a copy of DefaultTemplate.xaml and called it SolutionVersioningDefaultTemplate.xaml.
  4. Almost the first activity in the workflow is called “Update Build Number”. The default implementation for that activity uses the BuildNumberFormat variable to set the build number and I changed that to instead be “String.Format("{0}_{1}", BuildDetail.BuildDefinition.Name, VersionNumber)”. VersionNumber is a variable that I have added and before using it, it must be set to the version number that should be used for this build.
  5. I added the TfsVersion activity before “Update Build Number” and set its Action property to just “GetVersion”.


    I also added variables for Major, Minor and StartDate properties and made these configurable for the build. The StartDate is used when the “VersionFormat” is set to “Elapsed”, which means that the Build part of the version number will be the number of days that have elapsed since StartDate.
     

    With the steps above in place the name of the build and the name of drop folder will be as desired and the only thing that is left is to set the version number in the SolutionInfo.cs file so that all assemblies will get the same file version number.
  6. One important note about setting the version number is that you don’t want to check in the modifies SolutionInfo.cs file since that could trigger a new build and there are really no reason for doing it, so just don’t.
  7. To update the SolutionInfo.cs file is a two step process. First of all it is necessary to find the file to update and if it is found it should be updated.


    I choose to set the version before the build is labeling, so scroll down in the workflow until you find “If CreateLabel” (almost half way down).
  8. I used the standard activity FindMatchingFiles to search for the SolutionInfo.cs file and MatchPattern is set to “String.Format("{0}\**\{1}", SourcesDirectory, SolutionVersionFile)” where SolutionVersionFile is a variable that can be set to different values when creating the build definition. The MatchPattern variable supports the same syntax as the standard .NET Directory class supports for searching.
  9. If the SolutionInfo.cs file is found I use the TfsVersion activity again, but this time with the Action property set to “SetVersion”. I think that this solution would work also with AssemblyInfo files in the projects, but I haven’t tested that.
    If no file is found a warning is written to the user.

It took me a while to learn the basics of TFS Team Build and its workflow templates, but when the initial confusion is gone I believe it is powerful enough to support you in most scenarios. There are of course plenty of options for automating builds, but I guess you were interested in TFS Team Build if you made it this far. :)

Published den 3 juni 2012 20:29 by ericqu

Comments

 

Dew Drop – June 4, 2012 (#1,340) | Alvin Ashcraft's Morning Dew said:

juni 4, 2012 14:10
 

Tendulkaar said:

I wanna learn more, its seems to me confusing.

Thanks

juni 17, 2012 00:03
 

Team Building Melbourne said:

An informative blog on how to set a custom assembly version in a TFS Team Build. The blog is informative and useful for the taking.
september 4, 2012 11:24
Anonymous comments are disabled
Powered by Community Server, by Telligent Systems