一些好消息来自 this article 在Suzanne Cook在msdn上的博客(2003-05-30)上:

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

首先,文件版本和程序集版本不需要一致 彼此之间。我建议文件版本随 建造。但是,不要因为每次构建而更改组件版本 你可以分辨出同一版本的两个版本之间的区别 文件;使用该文件的版本。决定何时更改程序集 版本需要对构建的类型进行一些讨论,以考虑: 装运和不装运。

非发货版本
一般来说,我建议在发货版本之间保持非发货组件版本相同。这个 避免因版本而出现强名称程序集加载问题 不匹配。有些人喜欢使用发布者策略重定向新的 每个生成的程序集版本。我建议不要这样做 但是,非运输构建:它不能避免所有的加载 问题。例如,如果合作伙伴X-复制您的应用程序,他们可能不会 知道如何安装发布服务器策略。然后,您的应用程序将因 它们,即使它在你的机器上工作得很好。

但是,如果有不同的应用程序在同一个 机器需要绑定到程序集的不同版本,i 建议为这些生成提供不同的程序集版本,以便 每个应用程序正确使用一个,无需使用 加载等。

船舶建造
至于将该版本更改为装运版本是否是一个好主意,这取决于您希望如何将绑定 为最终用户工作。您希望这些构建并排还是 就位?两个版本之间有很多变化吗?它们是 会破坏一些客户吗?你在乎它会破坏他们吗(或者 您想强制用户使用您的重要更新吗?如果是的话,你 应该考虑增加程序集版本。但是,再一次, 考虑过多次这样做可能会丢弃用户的磁盘 带有过时的程序集。

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

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

• 当兼容性与新的relase中断时,从n.x转到n+1.0
• 添加不破坏兼容性的新功能时,从N.M转到N.M+1
• 添加错误修复后,从N.M.X转到N.M.X+1

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

哦,别忘了公布你提出的规则,这样人们就知道你的期望了。

语义版本控制有一套关于如何应用(以及何时应用)的指导原则和规则。很容易理解,而且很有效。

http://semver.org/

我首先建议您熟悉程序集版本和文件版本之间的差异。不幸的是,对于assemblyinfo文件,.net倾向于将这些文件视为相同的文件,因为它通常只放置assemblyversion并允许fileversion默认为相同的值。

既然您说这是一个共享程序集,我假设您的意思是它是在二进制级别上共享的(而不是通过将项目包含在各种解决方案中)。如果是这种情况,您希望非常慎重地更改程序集版本,因为.NET使用这种方式来强命名程序集(允许您将其放入GAC中),并构成“程序集全名”。当程序集版本更改时,它可以对使用它的应用程序进行破坏性更改,而无需在app.config文件中添加程序集重定向条目。

至于命名,我认为这取决于贵公司的命名规则(如果有的话)以及库的用途。对于ExMaple,如果此库提供的“核心”(或系统级)功能不是特定于任何特定产品或业务线的,则可以将其命名为:

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