[ACCEPTED]-.NET: Large revision numbers in AssemblyVersionAttribute-assemblyversionattribute

Accepted answer
Score: 47

A bit more Background information:

Why are build numbers limited to 65535?

As this 2 is unlikely to get changed, your options 1 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.
Score: 11

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

[assembly: AssemblyFileVersion("1.0.0.80000")]
Score: 9

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

Score: 5

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

Score: 2

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

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

Examples:

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

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

The AssemblyVersion is 20 1.0.0.0 and the BuildId is 66666.
--> The new AssemblyVersion 19 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 18 new AssemblyVersion becomes 1.0.0.11111. (Uses last 5 digits.)

Easy usage by following steps

Step 1: Define 17 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 16 could define it like this. It depends on 15 the style how you did define your already 14 existing variables.

variables:
  shortBuildId: '[not set]'

Step 2: Insert these tasks above 13 the existing tasks.

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

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

Note: In 8 this file you need an assembly version with 7 4 numbers (e.g. 1.0.0.0). If you have only 3 numbers 6 (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 5 in the second task related to your project.

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

Credit

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

Score: 0

I'd like to propose by way of answer the 27 following scheme for anyone using semver/gitflow:

AssemblyVersionAttribute SemVer/Gitflow
Major Version Major
Minor Version Minor
Build Number Patch
Revision Gitflow ID

Where 26 "Gitflow ID" is a digit followed 25 by 0000 - 9999, per the following:

Gitflow ID Branch
00000 - 09999 Release (alpha)
10000 - 19999 Release (beta)
20000 - 29999 Release (RC)
30000 - 65535 Development

The intuition 24 behind 00000 - 29999 is that these numbers represent 23 something of a logical negative pre-release 22 number, 30000 represents logical zero, and 30001 - 65535 represent 21 logical positive. More formally, this is 20 a kind of 10's complement representation, with offset K = 30000.

So for 19 example:

  1. Topic branch feature/A starts at 0.0.0.30000
  2. Simultaneously, topic branch feature/B also starts at 0.0.0.30000
  3. feature/B merges to dev at 0.0.0.31000 while feature/A is at 0.0.0.30021
  4. feature/A merges updates from dev at 0.0.0.31001
  5. feature/A merges to dev at 0.0.0.32000
  6. v1.0-alpha.1 release starts from dev at 1.0.0.00001
  7. v1.0-rc.3 at 1.0.0.20002
  8. Finally v1.0 released to Master at 1.0.0.30000
  9. Hotfix v1.0.1 applied at 1.0.1.30000
  10. Meanwhile v1.1 development continuing at 1.0.1.30002

The above suggests that the development 18 range 30000-65535 could be further subdivided for topic 17 branches, i.e. DDTTT, with DD ranging from 30 to 16 65 (max 65 - 30 + 1 = 36 dev PRs until release). Alternatively, the 15 whole range could be used for development 14 and topic branches without distinction; in 13 this case, merging from dev to topic would 12 have topic be dev + 1 and vice-versa. Either 11 case allows there to be multiple identical 10 version numbers at the topic branch level, but 9 only a single version number for any dev 8 commit. The DDTTT arrangement makes it clearer 7 which version number represents a dev commit 6 (e.g. 57000) at the expense of limiting the number 5 of dev commits in a release. However, assuming 4 a frequent enough release cadence, this 3 should not be a problem. At any rate, production 2 releases are clearly seen as having gitflow 1 IDs of 30000.

More Related questions