汇编命名和版本控制的最佳实践？

我正在寻找关于命名程序集和版本化它们的一些好方法.您多久递增一次主要版本或次要版本？

在某些情况下,我看到版本从1.0版本直接发布到3.0版本.在其他情况下,它似乎停留在版本1.0.2.xxxx.

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

从一些好的信息,这篇文章在苏珊·库克在MSDN(转贴2003-05-30)博客:

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

首先,文件版本和汇编版本不需要相互重合.我建议每个版本都会更改文件版本.但是,不要只为每个构建更改程序集版本,以便您可以区分同一文件的两个版本; 使用文件版本.决定何时更改程序集版本需要考虑要考虑的构建类型:运输和非运输.

非运输构建
通常,我建议在运输构建之间保持非运输组件版本相同.这避免了由于版本不匹配而导致强烈命名的程序集加载问题.有些人更喜欢使用发布者策略来重定向每个构建的新程序集版本.但是,对于非运输版本,我建议不要这样做:它不能避免所有加载问题.例如,如果合作伙伴对您的应用进行x复制,则他们可能不知道安装发布商政策.然后,即使它在您的计算机上运行正常,您的应用也会被破坏.

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

运输构建
至于为运输构建更改该版本是否是个好主意,这取决于您希望绑定如何为最终用户工作.您是否希望这些版本并排或就地？这两个版本之间有很多变化吗？他们打算打破一些客户吗？你是否担心它会破坏它们(或者你是否想强迫用户使用你的重要更新)？如果是,则应考虑增加程序集版本.但是,再一次,考虑这样做太多次可能会使用过时的程序集丢弃用户的磁盘.

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

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

兼容性与新版本相关时,从Nx转到N + 1.0

添加新功能时,从NM到N.M + 1不会破坏兼容性

添加错误修复后,从NMX转到NMX + 1

以上仅是一个示例 - 您需要定义对您有意义的规则.但是,用户通过查看版本快速判断是否存在不兼容性是非常好的.

哦,不要忘记发布你提出的规则,以便人们知道会发生什么.

语义版本控制有一套关于如何应用它(以及何时)的指南和规则.非常简单,它只是工作.

http://semver.org/

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