AssemblyVersion和AssemblyFileVersion属性是处理 .NET 程序集版本号的内置方法。虽然该框架提供了自动确定版本号（构建和修订，用 Microsoft 术语）的最不重要部分的能力，但我发现这种方法非常薄弱，毫无疑问还有很多其他方法。
所以我想问一下，为了更好地反映项目的实际版本，确定了哪些方法可以最好地完成版本号？您是否有预构建脚本将部分版本设置为日期和时间，或项目工作副本的存储库版本？你只是使用框架提供的自动生成吗？或者是其他东西？管理程序集/文件版本控制的最佳方法是什么？
I see many posts here about using the subversion revision number as a component of the assembly version. Beware: the 4 version numbers available in windows (a.b.c.d) are each limited to 16 bit (max = 65535). The subversion revision number can easily exceed this limit, especially if you host multiple projects in the same repository.
在我当前的项目中，我们使用 Subversion 修订号作为版本号的最不重要（构建）部分，并且我们使用 Nant 脚本来创建项目 AssemblyInfo 文件。我们对 AssemblyVersion 和 AssemblyFileVersion 属性使用相同的版本号。（其他三个部分是major.minor.point，其中major.minor 将在每次数据库架构更改时递增，并且point 在每次发布时递增。）
我们一开始只是简单地增加内部版本号，但这需要为每个版本签入版本文件，并在合并时引起冲突。当这被证明不可行时，我们开始使用 CruiseControl.NET 来生成内部版本号，但这使得手动重现特定版本变得困难。最终我们采用了当前的（Subversion-revision）方案。
注意：不幸的是，对于 .NET，不可能完美地从过去的版本重新创建构建，因为 .NET 编译器在编译时会将当前时间戳编码到目标文件中。每次编译相同的代码时，都会得到不同的目标文件。
在之前的工作中，我们使用了 Subversion，我运行了一个关于 ccnet 的 nant 脚本来提取存储库版本并将其用作最终编号。
在这项工作中，我们使用 VSS（快门），所以这不是一个真正的选择，所以我们制定了手动更新它的策略，并遵循以下准则：
我们还保持程序集和文件版本同步。程序集版本可以通过编程轻松读取，而文件版本可以在 Windows 资源管理器的详细信息模式中显示为一列。
我们的构建脚本将 TFS 中的变更集编号注入到版本中。这样我们就可以确切地知道构建中的签入。
我们有我们的 CruiseControl.NET 构建服务器将 perforce 更改列表编号嵌入到其中AssemblyFileVersion- 这让我们可以追溯构建服务器构建的任何程序集的源代码。（我们总是从主分支构建。）
对于客户将要引用的程序集，AssemblyVersion除非有重大更改，否则我们会保留常量，在这种情况下，我们会增加版本以确保针对新版本重新构建客户代码。
我们使用来自 subversion 的版本控制并让 buildscripts 更新程序集版本信息，因此源代码签入控制版本控制。
我们倾向于将发布（或构建）日期嵌入到程序集中。例如，如果今天构建，版本将是“2008.10.06”（构建脚本会更新它）。
AssemblyVersionAttribute 是程序集标识的一部分。改变这意味着它是一个不同的程序集，链接到该程序集的程序需要重新编译/链接，或者需要应用版本策略。我们没有发现这种吸引力，所以我们选择只为每个修补程序增加 AssemblyFileVersion，并且只为每个主要版本更改 AssemblyVersion。我们知道这个决定带回了一些 win32 dll 地狱。我们为每个构建增加 AssemblyFileVersion 并使用该版本标记/标记版本控制系统，以便我们知道二进制文件的来源。