Assembly Versioning with TeamCity

Question

I\'m working on a C#/VB.Net project that uses SVN and TeamCity build server. A dozen or so assemblies are produced by the build. I want to control the assembly versions so t

Answer 1

I'm leaving Hamish's answer as the accepted answer, but for completeness I thought it would be worth documenting the approach we finally adopted.

I maintain 2 seperate build configurations in TeamCity, one is the CI build and another is a build that runs weekly when there are any changes (or manually) and is our official release build. I went for the two-build approach because the build takes perhaps 40 minutes end-to-end and I wanted developers to get a quick feedback on any build issues when they commit changes. The CI build therefore is a subset of the full release build but it does build all of the code. The versioning also differs between the two builds:

• The CI build has version numbers {Major.minor.BuildCounter.SvnRevision}
  • BuildCounter starts from 0
  • does not tag the svn repository
• The Weekly/Release build has a similar versioning system, but
  • the build counter starts at (Major * 1000), so if Major is '8', the build counter starts from 8000.
  • Creates a tag called 'Build_{Version}' in the svn repository

The reason for this somewhat arbitrary choice is to allow us to clearly and simply distinguish between CI builds and Release builds.

We have a solution-wide file called AssemblyVersionInfo that is included (soft linked) in every project in the solution. The file contains (in essence) this:

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)

So developer builds all use the same static and readily identifiable version number, which is higher than anything produced by the build server so that in a versioning conflict, the developer's file wins.

On the build server, we us MSBuild Community Tasks to generate a new AssemblyVersionInfo file that overwrites the default content. We use the TeamCity build string as the new version. In this way, we can easily distinguish between the following 3 situations:

• A private build performed on the developer's workstation
• A CI build performed on the build server but which should not be released
• An officially sanctioned release build, which is tagged in the Svn repository

In another twist, note that I am setting AssemblyFileVersion, not AssemblyVersion. We force our assembly versions to be a static, fixed version string of 'Major.Minor.0.0'. We do this so that we are able to issue bug fix releases without having to worry about versioning issues. The AssemblyFileVersion lets us figure out what build a user has installed without it being part of the assembly's identity.