views:

411

answers:

3

I've inherited a .NET application that automatically updates it's version number with each release. The problem, as I see it, is in the verbosity of the version number: currently it is 3.5.3167.26981 which is a mouthful for the users to say when they are reporting bugs. What I would like is something more like this: 3.5 (build 3198) where I would have to manually update the major and minor versions, but the build number updates automatically. Even better, I don't want the build number to increment unless I am compiling in RELEASE mode.

Anyone know if there is a way to do this -- and how?

A: 

At a previous company we did something like this by writing an Ant task to get the current Subversion changeset string, which we used as the build number, appended after the major, minor, and tertiary numbers. You could do something like this with Visual Studio as well.

Brian Stewart
A: 

Use a '*' wildcard in the AssemblyVersion attribute. Documentation is here. Note that if the application is built from multiple assemblies, the version you care most about is the one for the .exe.

McKenzieG1
+3  A: 

In one of the project files, probably AssemblyInfo.cs, the assembly version attribute is set to [assembly: AssemblyVersion("3.5.*")] or something similar. The * basically means it lets Visual Studio automatically set the build and revision number.

You can change this to a hard coded value in the format <major version>.<minor version>.<build number>.<revision>

You are allowed to use any or all of the precision. For instance 3.5 or 3.5.3167 or 3.5.3167.10000.

You can also use compiler conditions to change the versioning based on whether you're doing a debug build or release build.

Joseph Daigle