.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

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.

Answer 2

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 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

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 5

This answer is for people, who use the Azure Build Pipeline, want to insert the BuildId value as last number of the assembly version and have a problem with a too large value of the BuildId. (> 65535)

My solution is to use the last 4 or 5 digits of the BuildId, which are injected into the file AssemblyInfo.cs.
I don't use the modulo operation, because than the version number would look totally different from the BuildId (after reaching the limit). Instead in my solution the "shorted" version looks similar to the BuildId.

Examples:

The AssemblyVersion is 1.0.0.0 and the BuildId is 333.
--> The new AssemblyVersion becomes 1.0.0.333. (Small number, no problem.)

The AssemblyVersion is 1.0.0.0 and the BuildId is 55555.
--> The new AssemblyVersion becomes 1.0.0.55555. (Still in range.)

The AssemblyVersion is 1.0.0.0 and the BuildId is 66666.
--> The new AssemblyVersion becomes 1.0.0.6666. (Uses last 4 digits. More isn't possible.)

The AssemblyVersion is 1.0.0.0 and the BuildId is 111111.
--> The new AssemblyVersion becomes 1.0.0.11111. (Uses last 5 digits.)

Easy usage by following steps

Step 1: Define the variable shortBuildId in your pipeline by this snippet.

variables:
- name: shortBuildId # note: The last 4 or 5 digits of the BuildId, because for the assembly version number the maximum value is 65535
  value: '[not set]' # will be set by powershell script

Alternatively you could define it like this. It depends on the style how you did define your already existing variables.

variables:
  shortBuildId: '[not set]'

Step 2: Insert these tasks above the existing tasks.

The first task creates the short BuildId and saves it to variable shortBuildId.

The second task updates the 4th version field in the file AssemblyInfo.cs. So the short buildId is injected into both, the AssemblyVersion and the AssemblyFileVersion.

Note: In this file you need an assembly version with 4 numbers (e.g. 1.0.0.0). If you have only 3 numbers (e.g. 1.0.0) it will not work.

- task: PowerShell@2
  displayName: Define short build ID
  # If allowed, use the last 5 digits. If they are larger than 65000, use the last 4 digits. Leading zeros are removed.
  # This is needed, because the full build ID can't be used as number for the assembly version.
  inputs:
    targetType: 'inline'
    script: |
      $shortId = $env:BUILD_BUILDID
      $shortId = $shortId % 100000
      if ($shortId -gt 65000) { $shortId = $shortId % 10000 }
      Write-Host "Build ID: $env:BUILD_BUILDID --> $shortId"
      Write-Host "##vso[task.setvariable variable=shortBuildId]$shortId" 
    showWarnings: true

- task: RegexReplace@3
  displayName: Insert shortBuildId into AssemblyInfo:
    InputSearchPattern: 'myProjectDirectory\Properties\AssemblyInfo.cs'
    FindRegex: '(\[assembly: (AssemblyVersion|AssemblyFileVersion)\("\d+\.\d+\.[0-9*]+)\.[0-9*]+("\)\])'
    ReplaceRegex: '$1.$(shortBuildId)$3'
    UseUTF8: true
    UseRAW: true

Step 3: Adjust the path in the second task related to your project.

Edit the value of InputSearchPattern.
If you want to insert the shortBuildId into all projects of your solution, just write InputSearchPattern: '**\AssemblyInfo.cs'

Credit

Thanks to Dr. Edmund Weitz for his great tool The Regex Coach, which is free to use.