你应该知道的程序集版本

程序集版本

一个程序集会有三个版本,每个版本都是做什么的呢,我们来看一下,每个版本号的用途及正确用法:

版本号

示例版本号:

Major(主版本号) Minor(次版本号) Build(内部版本号) Revision(修订号)
2 3 719 5

前两个编号构成了公众对版本的理解,公众会将这个版本号视为这个程序集的2.3版本,第三个编号719时程序集的build号,如果公司每天都生成程序集,那么每天都应该递增这个build版本号,最后一个5指出当前build的修订次数,如果因为某个原因,公司某一天必须要生成多次程序集(可能是为了修复一个造成其他什么事情都干不了的hit bug),revision 号就应该递增, Microsoft 采用的就是这个版本编号方案,强烈建议你也采用。

AssemblyFileVersion

这个版本号存储在 Win32 版本资源中,它仅供参考,CLR既不检查也不关心这个版本号。通常,可以先设置好版本的 major/minor 部门,这是希望公众看到的版本号,然后每生成一次就递增 build 和 revision 部分。

理想情况是 Microsoft 的工具(比如csc.exe 或者 al.exe)能够自动更新 build 和 revision(根据生成时的日期和时间)。
在 windows 系统资源管理器中能看到这个版本号,对客户系统进行故障诊断的时候,就可以根据它识别程序集版本是多少

AssemblyInformationVersion

这个版本号也存储在 Win32 版本资源中,同样仅供参考,CLR既不检查也不关心。
这个版本号的作用在于指出该程序集的产品的版本。例如,产品的2.0版本可能包含几个程序集,其中一个程序集标记为版本1.0,因为它是新开发的,在产品的1.0版本中不存在。

通常,可以设置这个版本号的 major 和 minor 部分来代表产品的公开版本号,以后每次打包所有程序集来生成完整产品,就递增 build 和 revision 部分。

AssemblyVersion

这个版本号存储在 AssemblyDef 清单数据中,CLR 在绑定到强命名程序集时会用到它,这个版本很重要,它唯一标识了程序集。开始开发程序集时应该设置好 major/minor/build/revision 部分,而且除非要开发程序集的下一个可部署版本,否则不应变动。如果程序集A引用了强命名程序集B,程序集B的版本会嵌入程序集A的 AssemblyRef 表。这样一来,当CLR需要加载程序集B时,就准确地知道当初生成和测试地是程序集B地哪个版本。

Reference

  • 《CLR via C#》第四版 -- 清华大学出版社

你可能感兴趣的:(你应该知道的程序集版本)