SVN Revision Version in .NET Assembly w/ out CC.NET

Question

Is there any way to include the SVN repository revision number in the version string of a .NET assembly? Something like Major.Minor.SVNRev

I've seen mention of doing this with something like CC.NET (although on ASP.NET actually), but is there any way to do it without any extra software? I've done similar things in C/C++ before using build batch scripts, but in was accomplished by reading the version number, then having the script write out a file called "ver.h" everytime with something to the effect of:

#define MAJORVER 4
#define MINORVER 23
#define SOURCEVER 965

We would then use these defines to generate the version string.

Is something like this possible for .NET?

Answer 1

Here's and C# example for updating the revision info in the assembly automatically. It is based on the answer by Will Dean, which is not very elaborate.

Example :

1. Copy AssemblyInfo.cs to AssemblyInfoTemplate.cs in the project's folder Properties.
2. Change the Build Action to None for AssemblyInfoTemplate.cs.

3. Modify the line with the AssemblyFileVersion to:

   [assembly: AssemblyFileVersion("1.0.0.$WCREV$")]

4. Consider adding:

   [assembly: AssemblyInformationalVersion("Build date: $WCNOW=%Y-%m-%d %H:%M:%S$; Revision date: $WCDATE=%Y-%m-%d %H:%M:%S$; Revision(s) in working copy: $WCRANGE$$WCMODS?; WARNING working copy had uncommitted modifications:$.")],

   which will give details about the revision status of the source the assembly was build from.

5. Add the following Pre-build event to the project file properties:

   subwcrev "$(SolutionDir)." "$(ProjectDir)Properties\AssemblyInfoTemplate.cs" "$(ProjectDir)Properties\AssemblyInfo.cs" -f

6. Consider adding AssemblyInfo.cs to the svn ignore list. Substituted revision numbers and dates will modify the file, which results in insignificant changes and revisions and $WCMODS$ will evaluate to true. AssemblyInfo.cs must, of course, be included in the project.

In response to the objections by Wim Coenen, I noticed that, in contrast to what was suggested by Darryl, the AssemblyFileVersion also does not support numbers above 2^16. The build will complete, but the property File Version in the actual assembly will be AssemblyFileVersion modulo 65536. Thus, 1.0.0.65536 as well as 1.0.0.131072 will yield 1.0.0.0, etc. In this example, there is always the true revision number in the AssemblyInformationalVersion property. You could leave out step 3, if you consider this a significant issue.

Edit: some additional info after having used this solution for a while.

1. It now use AssemblyInfo.cst rather than AssemblyInfoTemplate.cs, because it will automatically have Build Action option None, and it will not clutter you Error list, but you'll loose syntax highlighting.

2. I've added two tests to my AssemblyInfo.cst files:

   #if(!DEBUG)    
       $WCMODS?#error Working copy has uncommitted modifications, please commit all modifications before creating a release build.:$ 
   #endif 
   #if(!DEBUG)       
       $WCMIXED?#error Working copy has multiple revisions, please update to the latest revision before creating a release build.:$ 
   #endif
   

   Using this, you will normally have to perform a complete SVN Update, after a commit and before you can do a successful release build. Otherwise, $WCMIXED will be true. This seems to be caused by the fact that the committed files re at head revision after the commit, but other files not.

3. I have had some doubts whether the first parameter to subwcrev, "$(SolutionDir)", which sets the scope for checking svn version info, does always work as desired. Maybe, it should be $(ProjectDir), if you are content if each individual assembly is in a consistent revision.

Addition To answer the comment by @tommylux.

SubWcRev can be used for any file in you project. If you want to display revision info in a web page, you could use this VersionInfo template:

public class VersionInfo
{       
    public const int RevisionNumber = $WCREV$;
    public const string BuildDate = "$WCNOW=%Y-%m-%d %H:%M:%S$";
    public const string RevisionDate = "$WCDATE=%Y-%m-%d %H:%M:%S$";
    public const string RevisionsInWorkingCopy = "$WCRANGE$";
    public const bool UncommitedModification = $WCMODS?true:false$;
}

Add a pre-build event just like the one for AssemblyInfo.cst and you will have easy access to all relevant SubVersion info.

Answer 2

It is possible but you shouldn't: the components of the assembly version string are limited to 16-bit numbers (max 65535). Subversion revision numbers can easily become bigger than that so at some point the compiler is suddenly going to complain.

Answer 3

Have a look at SubWCRev - http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html

The assembly version numbers are usually in assemblyinfo.cs