.NET：AssemblyVersionAttribute 中的大修订号

Question

我们约定将构建的版本控制为[主要].[次要].[微].[修订版]，例如2.1.2.33546。

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

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

以便将版本号嵌入到程序集中。

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

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

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

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

Answer 1

更多背景信息：

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

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

• 采用修订模数 65535，这意味着您回到 1
• 使用版本号中的微字段来拆分版本号将修订版除以 1000 得到版本号。这意味着您的版本可能是 1.0.65.535
• 不要将 SVN 修订版存储在 AssemblyVersion 中，而是存储在 装配信息版本。 这样，您的应用程序仍然可以出于显示目的访问它，尽管您无法再使用 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 中的第四个版本字段。 因此，短 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'

Credit

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

Answer 6

我想通过回答任何使用 semver/gitflow 的人提出以下方案：

AssemblyVersionAttribute	SemVer/Gitflow
主要版本	主要
次要版本 次要	补丁
版本号	版本
://nvie.com/posts/a-successful-git-branching-model/ "	Gitflow ID

其中“Gitflow ID”是一个数字后跟 0000 - 9999，如下所示：

Gitflow ID	分支
00000 - 09999	版本 (alpha)
10000 - 19999	发布（测试版）
20000 - 29999	发布（RC）
30000 - 65535	开发

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

例如：

1. 主题分支 feature/A 从 0.0.0.30000 开始
2. ，同时，主题分支 feature/B 也从 0.0.0.30000 开始
3. feature/B 合并到 dev >0.0.0.31000 而 feature/A 位于 0.0.0.30021
4. feature/A 合并来自 dev 的更新 0.0.0.31001
5. feature/A 合并到 dev 的 code>0.0.0.32000
6. v1.0-alpha.1 版本从 dev 开始于 1.0.0.00001
7. v1.0-rc.3 at 1.0.0.20002
8. 最后v1.0 于 1.0.0.30000 发布到 Master 于
9. 1.0.1.30000 应用了修补程序 v1.0.1，
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）更加清晰，但代价是限制版本中开发提交的数量。 然而，假设发布频率足够频繁，这应该不是问题。 无论如何，生产版本显然具有 30000 的 gitflow ID。