What's wrong with my Visual Studio auto-increm

Question

i know Visual Studio has no way to increment the build number in a way that people would expect, but it support randomizing the build number:

My AssemblyInfo.cs file contains:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

And yet it gives, what appears to me, non-sensical results (even allowing for Visual Studio's pseudo-random version numbers):

So the simpler question is:

What do i put into AssemblyInfo.cs to make it work?

From MSDN (reformatted for clarity):

You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (*). For example,

[assembly:AssemblyVersion("2.3.25.1")]

indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as

[assembly:AssemblyVersion("1.2.*")] 

specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as

[assembly:AssemblyVersion("1.2.15.*")]

specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number.

The default build number increments daily. The default revision number is random.

i take that to mean that version numbers are:

[1.0.0.0]
major.minor.build.revision

while

[1.0.0.*]
major.minor.build.[random]

and

[1.0.*]
major.minor.[daynumber].[random]

Answer 1

I'm 99% sure that the problem you're experiencing is caused by this line:

[assembly: AssemblyFileVersion("1.0.*")]

The catch is that Visual Studio doesn't support auto-incrementing the AssemblyFileVersion, only the AssemblyVersion. So the rest of your code should be fine. Try simply commenting out that second line and see if you get the results that you're expecting. All of the version information for your file and product should be equivalent.

I don't know where exactly this is officially documented (other than the error message you receive if you try to enter the asterisk for the "File version" field in the "Assembly Information" dialog under Project Properties), but it works fine like this on every machine to which I've had access.

If you're completely sick of how Visual Studio does things when left to its own devices (you mention the silliness of its pseudo-random numbers), give this little gem of an add-in a try. It will change your life.

Answer 2

The screenshot shows you using the shell property sheet extension handler that displays the unmanaged version resource that's embedded in most EXE and DLL files, including .NET ones. Unfortunately, starting with Vista, that handler no longer displays optional fields in that resource. The ProductVersion field is a standard one but is not the [AssemblyVersion]. You'd have to add the corresponding attribute in AssemblyInfo.cs. For example:

[assembly: AssemblyInformationalVersion("1.2.3.4")]

Not a great name match, unfortunately. When it is missing, the compiler will copy the value of the [AssemblyVersion], that's how you ended up with the asterisk.

The compiler does actually emit the extra field in the resource. You can see it with File + Open + File, select your assembly, open the Version node and double-click resource #1:

Which was generated from:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyInformationalVersion("1.2.3.4")]
[assembly: AssemblyFileVersion("1.0.0.0")]

It's there, you just can't see in Explorer. Bummer, hopefully they'll fix that some day. Also note the generated [AssemblyVersion], the Revision number is 18404. It isn't random, I built this EXE at 10:13 am. That was 18404 * 2 seconds since midnight.