.NET: Large revision numbers in AssemblyVersionAttribute

Question

We have the convention of versioning our builds as [major].[minor].[micro].[revision], e.g. 2.1.2.33546.

Our build-script automatically updates an AssemblyInfo.cs file containing

[assembly: AssemblyVersion("x.y.z.w")]

in order to embed the version-number in the assembly.

But our Subversion-repository just reached revision #65535, which broke our build.

It turns out that each number in the version-number has a maximum value of 65534 (probably due to a Windows-restriction).

Have you encountered this problem? Any good solutions/workarounds?

We like the scheme of embedding the revision-number and we obviously can't just reset our Subversion-server :-)

Answer 1

One option might be to just use the [AssemblyFileVersion]; this still raises a warning, but it'll build, at least:

[assembly: AssemblyFileVersion("1.0.0.80000")]

Answer 2

According to MSDN, the components of the AssemblyVersionAttribute version number are limited to UInt16.MaxValue - 1 by the assembly meta data, i.e. you can't store larger numbers in an assembly file. The file version, as Marc Gravell suggests, might be enough for you, depending on who will read your version number.

Answer 3

We decided to use the same convention, and due to the limitations of Windows version numbers we chose to drop the "micro" part of our version numbers in order to preserve the revision number. Our version numbers are now [major].[minor].[revision / 10000].[revision % 10000], so the assemblies built from revision 65535 have the version 2.01.6.5535.

Answer 4

A bit more Background information:

Why are build numbers limited to 65535?

As this is unlikely to get changed, your options are:

• Take the Revision Modulo 65535, which means you are back to 1
• Use the Micro-Field in your version number to split the version number by dividing the revision by 1000. That means your version could be 1.0.65.535
• Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyInformationalVersion. That way your Application can still access it for display purposes, although you can't use Windows Explorer anymore to quickly check the SVN Revision
• Do not store the SVN Revision in the AssemblyVersion, but instead in the AssemblyProduct or AssemblyDescription fields. Again, that way your Application can still access it, but also Explorer will now show it in the Property Sheet.