38

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

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

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

4

4 回答 4

24

在 MSDN 上 Suzanne Cook 的博客上的这篇文章中提供了一些很好的信息（2003-05-30 发布）：

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

首先，文件版本和程序集版本不必相互一致。我建议文件版本随着每次构建而改变。但是，不要在每次构建时更改程序集版本，以便您可以分辨同一文件的两个版本之间的区别；为此使用文件版本。决定何时更改程序集版本需要对要考虑的构建类型进行一些讨论：运输和非运输。

非
发货版本 一般来说，我建议在发货版本之间保持非发货组件版本相同。这避免了由于版本不匹配而导致的强命名程序集加载问题。有些人更喜欢使用发布者策略为每个构建重定向新的程序集版本。但是，我建议不要将其用于非运输版本：它并不能避免所有加载问题。例如，如果合作伙伴 x 复制您的应用，他们可能不知道安装发布者政策。然后，您的应用程序将被他们破坏，即使它在您的机器上运行良好。

但是，如果同一台机器上的不同应用程序需要绑定到程序集的不同版本，我建议为这些构建提供不同的程序集版本，以便可以使用每个应用程序的正确版本，而无需使用 LoadFrom/etc。

发布
版本 至于为发布版本更改该版本是否是一个好主意，这取决于您希望绑定如何为最终用户工作。您希望这些构建是并排的还是就地的？两个版本之间有很多变化吗？他们会破坏一些客户吗？您是否关心它会破坏它们（或者您是否想强制用户使用您的重要更新）？如果是，您应该考虑增加程序集版本。但是，再一次，考虑这样做太多次可能会在用户的磁盘上乱扔过时的程序集。

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

于 2008-10-17T17:03:37.367 回答
21

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

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

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

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

于 2008-10-14T02:36:32.910 回答
9

语义版本控制有一套关于如何应用（以及何时）的指南和规则。很容易遵循，它只是工作。

http://semver.org/

于 2010-08-18T22:35:16.353 回答
6

我建议的第一件事是熟悉 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

于 2008-10-14T02:42:18.793 回答