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

Question

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

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

Answer 1

我在这里看到许多关于使用subversion版本号作为程序集版本的组件的帖子。 注意：Windows中可用的4个版本号（abcd）均限制为16位（最大值= 65535）。 subversion版本号很容易超过此限制，特别是如果您在同一个项目中托管多个项目库中。

Answer 2

在我当前的项目中，我们使用Subversion版本号作为版本号的最低有效（构建）部分，我们使用Nant脚本创建项目AssemblyInfo文件。我们对AssemblyVersion和AssemblyFileVersion属性使用相同的版本号。 （其他三个部分是major.minor.point，其中major.minor将在每次数据库模式更改时递增，并且每个版本的点都会递增。）

我们开始时只是增加了内部版本号，但这需要为每个版本检入版本文件，并在合并时引起冲突。当证明不可行时，我们开始使用CruiseControl.NET生成构建号，但这使得难以手动重现特定构建。最终我们进入了当前的（Subversion-revision）计划。

注意：遗憾的是，使用.NET时，无法从过去的版本中完美地重新构建构建，因为.NET编译器在编译时将当前时间戳编码到目标文件中。每次编译相同的代码时，都会得到一个不同的目标文件。

Answer 3

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

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

• 主要：功能或界面的重大（> 25％）更改或添加。
• Minor：功能或界面中的小改动或添加。
• 构建：破坏界面的微小更改。
• 修订版：修复了不会更改界面的构建。

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

Answer 4

我们的构建脚本将TFS中的变更集编号注入到版本中。这样我们就可以确切了解构建中的签名。

Answer 5

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

对于客户将引用的程序集，除非存在重大更改，否则我们将AssemblyVersion保持不变，在这种情况下，我们会增加版本以确保根据新版本重新构建客户代码。

Answer 6

我们使用subversion的版本控制，并让buildscripts更新程序集版本信息，因此源checkins控制版本控制。

Answer 7

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

Answer 8

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