使用程序集版本控制属性的最佳方式是什么？答案

【问题标题】：What is the best way to use assembly versioning attributes?使用程序集版本控制属性的最佳方式是什么？
【发布时间】：2009-04-25 20:38:35
【问题描述】：

AssemblyVersion 和 AssemblyFileVersion 属性是处理 .NET 程序集版本号的内置方法。虽然该框架提供了自动确定版本号（构建和修订，用 Microsoft 术语）的最不重要部分的能力，但我发现这种方法相当薄弱，而且毫无疑问还有很多其他方法。

所以我想问一下，为了使版本号更好地反映项目的实际版本，已经确定了哪些方法可以做到最好？您是否有将部分版本设置为日期和时间的预构建脚本，或项目工作副本的存储库版本？你只是使用框架提供的自动生成吗？或者是其他东西？管理程序集/文件版本控制的最佳方法是什么？

【问题讨论】：

标签： .net assemblies versioning

【解决方案1】：

我在这里看到很多关于使用 subversion 修订号作为程序集版本的组件的帖子。 注意：windows (a.b.c.d) 中可用的 4 个版本号均限制为 16 位（最大值 = 65535）。 颠覆修订号很容易超过此限制，尤其是当您在同一个中托管多个项目时存储库。

【讨论】：

是的 - 改用 AssemblyInformationalVersion 要好得多。
链接到所述属性：msdn.microsoft.com/en-us/library/…
您能否详细说明这有什么帮助？它是否尝试解析它并且只发出警告，而不是在超过时失败？这是一个真正的问题/耻辱。在版本号中添加 svn revs 确实很方便，但我们现在有 70,000 多个修订版，所以它不断下降。
@JonH：如果您尝试将这样的版本号放入 C# 代码中，例如如[assembly: AssemblyVersion("1.1.1.70000")] ，那么编译器将停止错误Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.1.1.70000' is invalid'.
是的......这就是我/我们现在所拥有的......我猜它是无法解决的。

【解决方案2】：

在我当前的项目中，我们使用 Subversion 修订号作为版本号的最不重要（构建）部分，并且我们使用 Nant 脚本来创建项目 AssemblyInfo 文件。我们对 AssemblyVersion 和 AssemblyFileVersion 属性使用相同的版本号。（其他三个部分是major.minor.point，其中major.minor 会在每次数据库架构发生变化时递增，而point 会在每次发布时递增。）

我们一开始只是简单地增加内部版本号，但这需要为每个版本签入版本文件，并在合并时导致冲突。当这被证明不可行时，我们开始使用 CruiseControl.NET 生成内部版本号，但这使得手动重现特定版本变得困难。最终我们采用了当前的（Subversion-revision）方案。

注意：不幸的是，对于 .NET，不可能完美地从过去的版本重新创建构建，因为 .NET 编译器在编译时会将当前时间戳编码到目标文件中。每次编译相同的代码时，都会得到不同的目标文件。

【讨论】：

有了CruiseControl.NET，您就可以完成每一个单独的构建，没有理由重新构建旧版本。如果您想为旧版本添加补丁，则必须在该特定版本的源代码管理中分支代码。
从存储中提取构建与能够证明您已捕获构建任何给定版本所需的所有部分之间存在差异。有许多环境变量会影响任何给定构建的创建。我的标准是结帐尽可能独立，这样您就可以在新机器上进行结帐并从头开始构建软件。使用 .Net（与 Java 相比）更难实现这一点，但仍然是一个有价值的目标。这意味着我已经将 Java、Ant 和所有库连同我的源代码一起签入。

【解决方案3】：

在之前的工作中，我们使用 Subversion，我运行了一个关于 ccnet 的 nant 脚本来提取存储库版本并将其用作最终编号。

在这项工作中，我们使用 VSS（快门），所以这不是一个真正的选择，因此我们制定了手动更新它的政策，并遵循以下准则：

主要：功能或界面发生重大 (> 25%) 更改或添加。
次要：功能或界面的小改动或添加。
构建：破坏界面的小改动。
修订：修复了不更改界面的构建。

我们还使程序集和文件版本保持同步。程序集版本可以通过编程轻松读取，而文件版本可以在 Windows 资源管理器的详细信息模式中显示为一列。

【讨论】：

【解决方案4】：

我们的构建脚本将 TFS 中的变更集编号注入到版本中。这样我们就可以准确地知道构建中有哪些签入。

【讨论】：

版本号的哪个字段？
好主意，但如果您仅将其限制在版本字段中的一个，主要、次要、构建、修订版，则可能会在 changeset-id 达到 0xfffe 后崩溃

【解决方案5】：

我们的 CruiseControl.NET 构建服务器将 perforce 更改列表编号嵌入到 AssemblyFileVersion 中——这让我们可以追溯构建服务器构建的任何程序集的源代码。（我们总是从主分支构建。）

对于客户将引用的程序集，我们保留 AssemblyVersion 常量，除非发生重大更改，在这种情况下，我们会增加版本以确保针对新版本重新构建客户代码。

【讨论】：

【解决方案6】：

我们使用来自 subversion 的版本控制并让 buildscripts 更新程序集版本信息，因此源代码签入控制版本控制。

【讨论】：

【解决方案7】：

我们倾向于将发布（或构建）日期嵌入到程序集中。例如，如果今天构建，版本将是“2008.10.06”（构建脚本会更新它）。

【讨论】：

听起来不错，但如果您每天进行多个构建或维护多个分支，我可以看到它很快就会分崩离析。
完全正确。嵌入内部版本号或构建时间可能是一种可行的解决方法。
你也可以使用时间，见stackoverflow.com/questions/971476/…

【解决方案8】：

AssemblyVersionAttribute 是程序集标识的一部分。改变这意味着它是一个不同的程序集，链接到该程序集的程序需要重新编译/链接，或者需要应用版本策略。我们没有发现这种吸引力，所以我们选择只为每个修补程序增加 AssemblyFileVersion，并且只为每个主要版本更改 AssemblyVersion。我们知道这个决定带回了一些 win32 dll 地狱。我们为每个构建增加 AssemblyFileVersion 并使用该版本标记/标记版本控制系统，以便我们知道二进制文件的来源。

【讨论】：

只有强命名的程序集才需要重新编译或策略文件。