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

【问题标题】：Best practices for assembly naming and versioning?程序集命名和版本控制的最佳实践？
【发布时间】：2010-09-17 00:31:45
【问题描述】：

我正在寻找一些关于命名程序集和对其进行版本控制的良好做法。您多久增加一次主要或次要版本？

在某些情况下，我看到版本直接从 1.0 版升级到 3.0 版。在其他情况下，它似乎卡在 1.0.2.xxxx 版本。

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

【问题讨论】：

您问的是 .NET 吗？我怀疑这个问题是关于汇编语言的......
这是关于 .Net 的。除了技术，我还对版本控制背后的过程感兴趣。
版本相关问题：stackoverflow.com/q/3768261/531524

标签： c# .net assemblies versioning

【解决方案1】：

来自this article 在 MSDN 上 Suzanne Cook 的博客（发布于 2003-05-30）上的一些有用信息：

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

首先，文件版本和程序集版本不必一致彼此。我建议文件版本随着每个建造。但是，不要在每次构建时更改程序集版本你可以分辨出同一个版本的两个版本之间的区别文件;为此使用文件版本。决定何时更换装配体版本对要考虑的构建类型进行了一些讨论：航运和非航运。

非发货版本
一般来说，我建议在发货版本之间保持非发货程序集版本相同。这避免由于版本引起的强命名程序集加载问题不匹配。有些人更喜欢使用发布者政策来重定向新的每个构建的程序集版本。我建议不要这样做然而，非运输构建：它并没有避免所有的加载问题。例如，如果合作伙伴 x 复制您的应用，他们可能不会知道安装发布者政策。然后，您的应用程序将因他们，即使它在你的机器上工作得很好。

但是，如果存在不同应用程序在同一个应用程序上的情况机器需要绑定到你程序集的不同版本，我建议为这些构建提供不同的程序集版本，以便每个应用程序都可以使用正确的，而无需使用加载自/等。

运送构建
至于更改该版本以运送构建是否是个好主意，这取决于您希望如何绑定为最终用户工作。您希望这些构建是并排的还是到位？两个版本之间有很多变化吗？他们是会破坏一些客户吗？你是否关心它会破坏它们（或做您想强制用户使用您的重要更新）？如果是，你应考虑增加程序集版本。但话又说回来，考虑这样做太多次会乱扔用户的磁盘带有过时的组件。

当您更改程序集版本时
要将硬编码版本更改为新版本，我建议为版本设置一个变量在头文件中并将源中的硬编码替换为多变的。然后，在构建期间运行预处理器以放入正确的版本。我建议在发货后立即更改版本，之前不是，所以有更多的时间来捕捉错误，因为改变。

【讨论】：

【解决方案2】：

语义版本控制有一套关于如何应用（以及何时应用）的指南和规则。非常简单易懂，而且效果很好。

http://semver.org/

【讨论】：

【解决方案3】：

我建议的第一件事是熟悉 Assembly 版本和 File 版本之间的区别。不幸的是，当涉及到 AssemblyInfo 文件时，.NET 倾向于将这些视为相同，因为它通常只放置 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），其中 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

【讨论】：

【解决方案4】：

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

当与新版本的兼容性中断时，从 N.x 转到 N+1.0
当添加新功能且不会破坏兼容性时，从 N.M 转到 N.M+1
添加错误修复后，从 N.M.X 转到 N.M.X+1

上面只是一个例子——你想定义对你有意义的规则。但是对于用户来说，仅通过查看版本就可以快速判断是否存在不兼容性是非常好的。

哦，别忘了公布你想出的规则，让人们知道会发生什么。

【讨论】：

出于营销原因，通常有必要从 1.0 迁移到 2.0（我们不要忘记谁买单！）。新的主要版本比次要版本更容易收取额外费用。