Automatically sync the two numbers on each build.

Recall that version numbers are of the form Major.Minor.BuildDay.BuildTime . For quite some time I used Visual Studio’s auto-generated build numbers. Basically you edit your project’s AssemblyVersion.cs to [assembly : AssemblyVersion("X.Y.*")] and, every time you build your project, your binaries get stamped with a version number of the form 1.0.5457.29870 .

Those last two numbers are generated according to the time of the build — the first is related with the day of build (the number of days since the year 2000) and the second with the time of the build (the number of seconds since last midnight). Setting only the last to be * can be bad — if you built the solution late in a day and early in the following day, the later build would have an earlier version number. I recommend always using X.Y.* instead of X.Y.Z.* because your version number will ALWAYS increase this way.

However when you have to deliver new binaries on a daily basis, these random generated numbers provide little information other than a sequence. Imagine your client screaming that the version 1.0.5457.29870 doesn’t work. How are you going to figure out which source code (or SVN release) generated that binary?

The solution is to embed SVN’s revision number into your binaries’ version number. That way, when you check the version number of an executable you immediately know which SVN commit was used to build that binary. The steps are quite easy:

Copy your existing AssemblyInfo.cs file into a file named AssemblyInfo_template.cs . This will become our template file, used by Visual Studio’s version generator. Add AssemblyInfo.cs to SVN’s ignore list. This file will be generated/ovewritten everytime you rebuild your solution. In the new AssemblyInfo_template.cs file edit the AssemblyVersion with the desired SubWCRev.exe keywords. Recall that version numbers are of the form Major.Minor.BuildDay.BuildTime . In my case I wanted the Major number to be set manually, the Minor number to be automatically set by SVN’s revision, and the last two dynamically generated by Visual Studio. Therefore, I edited [assembly : AssemblyVersion("1.0.0.0")] to [assembly: AssemblyVersion("2.$WCREV$.*")] If you want the FileVersion to be the same as the AssemblyVersion, just delete the FileVersion entry. Finally we need to tell Visual Studio to generate the AssemblyInfo.cs on every build event. Right-click your project and select “Properties”. Then select the “Build Events” tab and in the “Pre-build event command line” type the following command below.

The first part should be the fullpath to your SubWCRev executable. The first parameter is the working copy path, the second is the source file containing the keywords (our template file) and the third is the destination file (the “compiled” AssemblyInfo.cs).

"C:\Program Files\TortoiseSVN\bin\SubWCRev.exe" $(ProjectDir). $(ProjectDir)Properties\AssemblyInfo_template.cs $(ProjectDir)Properties\AssemblyInfo.cs

WARNING: Do not add the AssemblyInfo_template.cs to your Visual Studio project. If you do, you’ll have compilation errors about duplicated attributes! However, do add AssemblyInfo_template.cs to your SVN repository.

To sum it up

Everytime you rebuild your project, Visual Studio will embed the most recent SVN’s revision number in your binaries’ version number. Don’t forget to commit your changes before rebuilding your project, so that your file’s version match SVN’s revision number. Also note that a build won’t update AssemblyInfo.cs, for that you need a rebuild.