我正在寻找一些关于程序集命名和版本控制的好方法。你通常会在哪些情况下增加主版本或次版本?
有些情况下,我看到发布版本从1.0直接跳到3.0,而在其他情况下,它似乎一直停留在版本1.0.2.xxxx。
这将用于公司中多个项目中使用的共享程序集。期待一些好的建议。
我正在寻找一些关于程序集命名和版本控制的好方法。你通常会在哪些情况下增加主版本或次版本?
有些情况下,我看到发布版本从1.0直接跳到3.0,而在其他情况下,它似乎一直停留在版本1.0.2.xxxx。
这将用于公司中多个项目中使用的共享程序集。期待一些好的建议。
以下是Suzanne Cook在MSDN博客上发布的这篇文章(发布时间为2003-05-30)中的一些有用信息:
首先,文件版本和程序集版本不必相符。我建议每次构建更改文件版本。但是,不要仅仅为了区分同一文件的两个版本而每次构建都更改程序集版本;使用文件版本来进行区分。决定何时更改程序集版本需要讨论要考虑的构建类型:发布和非发布。
非发布构建
一般来说,我建议在发布构建之间保持非发布程序集版本不变。这样可以避免由于版本不匹配而导致的强名称程序集加载问题。有些人喜欢使用出版者策略来重定向每个构建的新程序集版本。然而,我不建议在非发布构建中使用它:它不能避免所有的加载问题。例如,如果合作伙伴复制您的应用程序,则他们可能不知道安装出版者策略。然后,他们的应用程序将无法正常工作,即使在您的机器上它可以正常工作。
但是,如果有情况下,同一台机器上的不同应用程序需要绑定到您程序集的不同版本,那么我建议为这些构建分配不同的程序集版本,以便每个应用程序可以使用正确的版本,而无需使用LoadFrom /等。
发布构建
至于是否更改该版本以用于发布构建,这取决于您希望绑定如何为最终用户工作。您想让这些构建并排或就地放置吗?两个构建之间有很多变化吗?它们会破坏一些客户吗?您是否关心它们(或者您想强制用户使用重要更新)?如果是,则应考虑递增程序集版本。但是,请再次考虑,过多地执行此操作可能会使用户的磁盘上充满过时的程序集。
更改程序集版本时
要将硬编码版本更改为新版本,我建议在头文件中设置一个变量来保存版本,并将源代码中的硬编码替换为该变量。然后,在构建期间运行预处理器以插入正确的版本。我建议在发布之后立即更改版本,而不是在发布之前,以便有更多时间捕获由于更改而导致的错误。
定义版本的一种方法是对每个部分赋予语义含义:
上面只是一个例子--您需要定义适合自己的规则。但用户可以通过查看版本号快速判断是否存在不兼容性,这非常有用。
哦,还别忘了发布您制定的规则,以便人们知道要期望什么。
CompanyName.Framework.Core
CompanyName.Shared
CompanyName.Core
CompanyName.Framework
http://msdn.microsoft.com/en-us/library/51ket42z.aspx
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx