【发布时间】：2010-11-27 00:46:55
【问题描述】：
我期待为即将到来的项目实施每日构建。
但在此之前，我需要知道如何正确地对程序集进行版本控制。
我有以下顾虑：
- 每个程序集应该有一个独立的版本号还是应该共享相同的版本？
- 我应该使用 * 版本进行构建和修订吗？
- 修订是否与日常构建相关？
【问题讨论】：
标签： visual-studio project-management versioning
【发布时间】：2010-11-27 00:46:55
【问题描述】：
所以每个程序集都应该具有相同的版本，通常是发布版本的组合，即 3.4 + 内部版本号，该版本号表示该版本已在构建服务器上编译的次数。修订是相关的，因为它展示了您为该版本创建的构建数量。您可以通过以下两种方式之一真正做到这一点。第一种方法是，如果您计划发布即 3.4，那么当您开始处理该版本时，这就是您的主要版本号，而您的次要版本号会随着构建而增加。另一种方法是严格控制构建版本，当您准备好发布到 QA / Regression 时，您将主要版本设置为 3.4，并将次要版本号保留为 0。您可以通过这种方式严格控制直到你释放。这样，您可以通过次要版本号控制您的服务包编号。希望这会有所帮助。
【讨论】：
答案实际上取决于您尝试使用程序集版本号来完成什么。如果您正在执行 ClickOnce 部署并希望独立下载更新的程序集，则需要对每个程序集进行独立版本控制——否则，我认为程序集版本与软件版本号匹配通常很好。在更复杂的场景中，您可能需要其他策略。
我在以前的公司使用的方案是 major.minor.revision.build - 所以在产品的 1.0 版本中，每个程序集的程序集版本和程序集文件版本是 1.0.0.1129（例如）。这使得匹配哪些程序集是哪个软件版本的一部分变得很容易，直到内部版本号。我们在每个 AssemblyInfo.cs 文件中使用预编译搜索和替换来完成此操作，以将令牌替换为我们的自动构建过程提供的版本号。
【讨论】：
我们使用以下步骤将产品中的所有组件标记为相同的版本号：
将所有程序集链接到一个 AssemblyInfoCommon.cs 包含 版本号信息：见here 举个例子。
生成 AssemblyInfoCommon.cs 文件作为构建的一部分 使用（在我们的例子中）NAnt asminfo 任务、Cruise Control .NET 和 SVN 修订标签器
在我们的例子中，我们不使用 * 版本。所有部署的版本都构建在构建服务器上。我们不用担心桌面上的版本号。
【讨论】：
-
+1 用于构建服务器的构建号。构建应该是可重复的，这意味着它们应该被编写脚本，并且在您的桌面上执行它们很容易变得懒惰并且“只知道”如何去做而不是通过创建构建脚本的麻烦。
我通常同意所有程序集都应该具有相同的版本号；但是，我要对此提出一个警告。如果其中一个程序集在该项目之外的其他地方使用，或者如果它被认为是自己的项目，则它应该有自己的版本号。它也应该从该解决方案中移出并进入它自己的解决方案。我提到这一点的唯一原因是我见过很多场合，人们有一个在其他几个地方使用的组件，但主要是在一个地方，他们试图保持版本正确。这样做是个坏主意。我认为单一职责原则也适用于解决方案/项目级别。
就编号而言，我同意 Guy Starbuck (major.minor.revision.build) 的观点。这就是我一直这样做的方式，并且一直运作良好。
【讨论】：
我们有一个经常发布（大约每月 1 个）的大型应用程序（数百个程序集）。我们追求“为每个程序集提供相同的版本”，但它始终让我感到不安，即 1 个版本的程序集与另一个版本的程序集完全不兼容，尽管这些程序集的接口很少（如果有的话）改变。
如果您遇到这种情况，那么您可能会从单独的程序集版本控制中受益 - 每次更新程序集时，只需在您真正想要中断程序集绑定的情况下增加版本号（例如，如果接口更改，或这些更改非常重要，以至于您希望防止有人意外使用以前的版本。
【讨论】：