程序集版本
一个程序集会有三个版本，每个版本都是做什么的呢，我们来看一下，每个版本号的用途及正确用法：
版本号
示例版本号：
| 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 系统资源管理器中能看到这个版本号，对客户系统进行故障诊断的时候，就可以根据它识别程序集版本是多少
Assembly@R_784_4045@ionVersion
这个版本号也存储在 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#》第四版 -- 清华大学出版社@H_502_58@
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
