What happened to the assembly number syntax for Auto-increment Visual Studio?

Question

I know that Visual Studio is not able to increase the build number as people expected, but it supports the build number randomization :

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 it seems to me to be insensitive results (even taking into account the pseudorandom version numbers of Visual Studio):

So a simpler question:

What do I insert in AssemblyInfo.cs to make it work?

From MSDN (reformatted for clarity):

You can specify all values ​​or can accept the default build number, revision number, or both with an asterisk (*). For instance,

 [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. Version number e.g.

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

defines 1 as the major version, 2 as the minor version, and accepts default numbers and revisions by default. version number e.g.

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

defines 1 as the major version, 2 as the minor version, 15 as the build number and defaults to the revision number.

The default number for the assembly is increasing daily. The default version number is random.

I believe the version numbers are:

 [1.0.0.0] major.minor.build.revision 

a

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

and

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

Answer 1

I am 99% sure that the problem you are facing is caused by this line:

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

The catch is that Visual Studio does not support auto-increment of AssemblyFileVersion , only AssemblyVersion . . So the rest of your code should be fine. Just try to comment on this second line and see if you get the results you expect. All version information for your file and product should be equivalent.

I don’t know where exactly this is officially documented (except for the error message that you get if you try to enter an asterisk in the File Version field in the Assembly Information dialog box in the Project Properties section), but it works fine on all the machines that I had access to.

If you are completely tired of how Visual Studio does something when left on your devices (you mention the stupidity of your pseudo-random numbers), give this little gem of the add-in a try. It will change your life.

Answer 2

The screenshot shows that you are using a shell properties sheet extension handler that displays an unmanaged version resource that is built into most EXE and DLL files, including .NET. Unfortunately, starting with Vista, this handler no longer displays additional fields in this resource. The ProductVersion field is standard but not [AssemblyVersion]. You need to add the appropriate attribute in AssemblyInfo.cs. For instance:

[assembly: AssemblyInformationalVersion ("1.2.3.4")]

Unfortunately, a great name does not fit. When it is absent, the compiler will copy the [AssemblyVersion] value, which is how you ended up with an asterisk.

The compiler really allocates an extra field in the resource. You can see it using File + Open + File, select your assembly, open the node version and double-click resource # 1:

What was created from:

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

It is there, you simply cannot see in Explorer. Bummer, I hope one day fix it. Also pay attention to the generated [AssemblyVersion], the version number is 18404. It is no coincidence that I built this EXE at 10:13. It has been 18404 * 2 seconds since midnight.