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?
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 :
Modify the line with the AssemblyFileVersion to:
[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]
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.
Add the following Pre-build event to the project file properties:
subwcrev "$(SolutionDir)." "$(ProjectDir)Properties\AssemblyInfoTemplate.cs" "$(ProjectDir)Properties\AssemblyInfo.cs" -f
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.
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.
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.