程序集命名和版本控制的最佳实践？

Question

我正在寻找一些关于程序集命名和版本控制的好方法。你通常会在哪些情况下增加主版本或次版本？

有些情况下，我看到发布版本从1.0直接跳到3.0，而在其他情况下，它似乎一直停留在版本1.0.2.xxxx。

这将用于公司中多个项目中使用的共享程序集。期待一些好的建议。

- Gulzar

---

你是在问.NET吗？我怀疑这个问题不是关于汇编语言的... - bk1e

这是关于 .Net 的。除了技术，我更感兴趣的是版本控制背后的过程。 - Gulzar Nazim

一个关于版本的相关问题：https://dev59.com/Im865IYBdhLWcg3wivGi - Huseyin Yagli

Answer 1

以下是Suzanne Cook在MSDN博客上发布的这篇文章（发布时间为2003-05-30）中的一些有用信息：

何时更改文件/程序集版本

首先，文件版本和程序集版本不必相符。我建议每次构建更改文件版本。但是，不要仅仅为了区分同一文件的两个版本而每次构建都更改程序集版本；使用文件版本来进行区分。决定何时更改程序集版本需要讨论要考虑的构建类型：发布和非发布。

非发布构建
一般来说，我建议在发布构建之间保持非发布程序集版本不变。这样可以避免由于版本不匹配而导致的强名称程序集加载问题。有些人喜欢使用出版者策略来重定向每个构建的新程序集版本。然而，我不建议在非发布构建中使用它：它不能避免所有的加载问题。例如，如果合作伙伴复制您的应用程序，则他们可能不知道安装出版者策略。然后，他们的应用程序将无法正常工作，即使在您的机器上它可以正常工作。

但是，如果有情况下，同一台机器上的不同应用程序需要绑定到您程序集的不同版本，那么我建议为这些构建分配不同的程序集版本，以便每个应用程序可以使用正确的版本，而无需使用LoadFrom /等。

发布构建
至于是否更改该版本以用于发布构建，这取决于您希望绑定如何为最终用户工作。您想让这些构建并排或就地放置吗？两个构建之间有很多变化吗？它们会破坏一些客户吗？您是否关心它们（或者您想强制用户使用重要更新）？如果是，则应考虑递增程序集版本。但是，请再次考虑，过多地执行此操作可能会使用户的磁盘上充满过时的程序集。

更改程序集版本时
要将硬编码版本更改为新版本，我建议在头文件中设置一个变量来保存版本，并将源代码中的硬编码替换为该变量。然后，在构建期间运行预处理器以插入正确的版本。我建议在发布之后立即更改版本，而不是在发布之前，以便有更多时间捕获由于更改而导致的错误。

- Gulzar

Answer 2

定义版本的一种方法是对每个部分赋予语义含义：

• 当与新版本不兼容时，将版本从 N.x 更改为 N+1.0
• 当添加新功能而不会破坏兼容性时，将版本从 N.M 更改为 N.M+1
• 当修复错误时，将版本从 N.M.X 更改为 N.M.X+1

上面只是一个例子--您需要定义适合自己的规则。但用户可以通过查看版本号快速判断是否存在不兼容性，这非常有用。

哦，还别忘了发布您制定的规则，以便人们知道要期望什么。

- andy

---

往往出于市场的考虑（别忘了谁付账！），我们需要从1.0版本升级到2.0版本。对于一次大版本更新，涨价更容易被接受，而小版本更新则不然。 - Jon B

Answer 3

语义化版本控制有一系列的指南和规则来实现它的应用（以及何时使用）。这些指南非常简单易懂，而且非常实用。 http://semver.org/

- Bil Simser

Answer 4

我建议您首先熟悉程序集版本和文件版本之间的差异。不幸的是，.NET在AssemblyInfo文件中通常只放置AssemblyVersion并允许FileVersion默认为相同值。因此，在这种情况下，您需要非常谨慎地更改程序集版本，因为.NET使用它来强名称程序集（以允许您将其放入GAC），同时也构成“程序集全名”。当程序集版本更改时，可能会对使用它的应用程序产生破坏性影响，而无需在app.config文件中添加程序集重定向条目。

至于命名，我认为它取决于您公司的命名规则（如果有）和库的用途。例如，如果该库提供了“核心”（或系统级）功能，不针对任何特定产品或业务线，您可以将其命名为：

CompanyName.Framework.Core 

如果它是一个更大的库的一部分，或者只是

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

就版本号何时递增而言，这仍然相当主观，取决于您认为构建号的每个部分代表什么。默认的 Microsoft 方案是 Major.Minor.Build.Revision，但这并不意味着您不能自己定义。最重要的是在您的策略中保持一致，并确保所有产品的定义和规则都有意义。

在我看到的几乎每个版本方案中，前两部分都是 Major.Minor。主要版本号通常在有大更改和/或破坏性更改时递增，而次要版本号通常递增以指示发生了某些变化，这些变化并非破坏性变化。其他两个数字相对较为主观，可以是“构建”（通常是序列日期值或每天更新的顺序递增数字）和“修订”或补丁号。我还看到它们被反转（给出 Major.Minor.Revision.Build），其中构建是来自自动构建系统的顺序递增数字。

请记住，当导出程序集时，程序集的主要和次要版本用作类型库版本号。

最后，请查看以下资源以获取更多信息：

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx

- Scott Dorman