.NET：AssemblyVersionAttribute 中的大修订号

Question

我们有将构建版本控制为 [major].[minor].[micro].[revision] 的惯例，例如 2.1.2.33546。

我们的构建脚本会自动更新 AssemblyInfo.cs 文件，其中包含

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

为了在程序集中嵌入版本号。

但是我们的 Subversion 存储库刚刚达到修订版 #65535，这破坏了我们的构建。

事实证明，版本号中的每个数字的最大值为 65534（可能是由于 Windows 限制）。

你遇到过这个问题吗？ 有什么好的解决方案/解决方法吗？

我们喜欢嵌入修订号的方案，我们显然不能只重置我们的 Subversion-server :-)

Answer 1

更多背景信息：

为什么内部版本号限制为 65535？

由于这不太可能改变，您的选择是：

• 取 Revision Modulo 65535，这意味着你回到了 1
• 使用版本号中的 Micro-Field 通过将修订除以 1000 来拆分版本号。这意味着您的版本可能是 1.0.65.535
• 不要将 SVN 修订版存储在 AssemblyVersion 中，而是存储在AssemblyInformationalVersion中。 这样，您的应用程序仍然可以访问它以进行显示，尽管您不能再使用 Windows 资源管理器来快速检查 SVN 修订版
• 不要将 SVN 修订版存储在 AssemblyVersion 中，而是存储在 AssemblyProduct 或 AssemblyDescription 字段中。 同样，您的应用程序仍然可以访问它，而且资源管理器现在将在属性表​​中显示它。

Answer 2

一种选择可能是只使用[AssemblyFileVersion] ； 这仍然会引发警告，但至少会构建：

[assembly: AssemblyFileVersion("1.0.0.80000")]

Answer 3

我们决定使用相同的约定，并且由于 Windows 版本号的限制，我们选择删除版本号的“微”部分以保留修订号。 我们的版本号现在是[major].[minor].[revision / 10000].[revision % 10000] ，因此从版本 65535 构建的程序集的版本为 2.01.6.5535。

Answer 4

根据 MSDN ，AssemblyVersionAttribute 版本号的组件由程序集元数据限制为UInt16.MaxValue - 1 ，即您不能在程序集文件中存储更大的数字。 正如 Marc Gravell 所建议的，文件版本可能对您来说就足够了，这取决于谁会阅读您的版本号。

Answer 5

此答案适用于使用Azure Build Pipeline的人，他们希望将BuildId值插入为程序集版本的最后一个数字，并且遇到BuildId值过大的问题。 (> 65535)

我的解决方案是使用BuildId的最后 4 或 5 位，它们被注入到文件AssemblyInfo.cs中。
我不使用模运算，因为版本号看起来与 BuildId 完全不同（达到限制后）。 相反，在我的解决方案中，“短路”版本看起来类似于 BuildId。

例子：

AssemblyVersion为1.0.0.0 ， BuildId为 333。
--> 新的 AssemblyVersion 变为1.0.0.333 。 （数量少，没问题。 ）

AssemblyVersion为1.0.0.0 ， BuildId为 55555。
--> 新的 AssemblyVersion 变为1.0.0.55555 。 （还在范围内。 ）

AssemblyVersion为1.0.0.0 ， BuildId为 66666。
--> 新的 AssemblyVersion 变为1.0.0.6666 。 （使用最后 4 位数字。不可能更多。 ）

AssemblyVersion为1.0.0.0 ， BuildId为 111111。
--> 新的 AssemblyVersion 变为1.0.0.11111 。 （使用最后 5 位数字。 ）

按照以下步骤轻松使用

第 1 步：通过此代码段在您的管道中定义变量shortBuildId 。

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

或者，您可以像这样定义它。 这取决于您如何定义已经存在的变量的样式。

variables:
  shortBuildId: '[not set]'

第 2 步：将这些任务插入现有任务之上。

第一个任务创建短 BuildId 并将其保存到变量shortBuildId 。

第二个任务更新文件AssemblyInfo.cs中的第 4 个版本字段。 因此，短 buildId 被注入到AssemblyVersion和AssemblyFileVersion中。

注意：在此文件中，您需要一个带有 4 个数字的程序集版本（例如1.0.0.0 ）。 如果您只有 3 个数字（例如1.0.0 ），它将不起作用。

- 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

第 3 步：调整与您的项目相关的第二个任务中的路径。

编辑InputSearchPattern的值。
如果要将 shortBuildId 插入到解决方案的所有项目中，只需编写InputSearchPattern: '**\AssemblyInfo.cs'

信用

感谢 Edmund Weitz 博士的伟大工具The Regex Coach ，它可以免费使用。

Answer 6

我想为任何使用 semver/gitflow 的人提出以下方案：

程序集版本属性	SemVer / Gitflow
主要版本	主要的
次要版本	次要的
内部版本号	修补
修订	Gitflow ID

其中“Gitflow ID”是一个数字，后跟0000 - 9999 ，根据以下内容：

Gitflow ID	分支
00000 - 09999	发布（阿尔法）
10000 - 19999	发布（测试版）
20000 - 29999	发布 (RC)
30000 - 65535	发展

00000 - 29999背后的直觉是这些数字代表某种逻辑负预发布数字， 30000代表逻辑零， 30001 - 65535代表逻辑正数。 更正式地说，这是一种10 的补码表示，偏移量K = 30000 。

例如：

1. 主题分支功能/A 从0.0.0.30000开始
2. 同时，主题分支特征/B 也从0.0.0.30000开始
3. 功能/B 在0.0.0.31000处合并到开发，而功能/A 在0.0.0.30021
4. feature/A 在0.0.0.31001合并来自 dev 的更新
5. 功能/A 在0.0.0.32000处合并到 dev
6. v1.0-alpha.1 版本从 dev 1.0.0.00001开始
7. v1.0-rc.3 在1.0.0.20002
8. 最终 v1.0 在1.0.0.30000发布给 Master
9. 修补程序 v1.0.1 在1.0.1.30000应用
10. 同时 v1.1 开发继续在1.0.1.30002

以上表明开发范围30000-65535可以进一步细分为主题分支，即DDTTT ， DD范围从30到65 （最多 65 - 30 + 1 = 36 个开发 PR 直到发布）。 或者，整个范围可以不加区别地用于开发和主题分支； 在这种情况下，从 dev 合并到 topic 的 topic 是 dev + 1，反之亦然。 任何一种情况都允许在主题分支级别有多个相同的版本号，但对于任何开发提交只有一个版本号。 DDTTT安排使哪个版本号代表开发提交（例如57000 ）更加清晰，但以限制发布中的开发提交数量为代价。 但是，假设发布节奏足够频繁，这应该不是问题。 无论如何，生产版本清楚地被视为具有 gitflow ID 30000 。