你应该知道的程序集版本

程序集版本

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

版本号

示例版本号：

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#》第四版 -- 清华大学出版社