| major（主版本号） | minor（次版本号） | build（内部版本号） | revision（修订号） | |
| 示例 | 2 | 5 | 719 | 2 |
1，版本号：
表展示了示例版本号：2.5.719.2。前两个编号构成了公众对版本号的理解。公众会将这个例子看成是程序集的2.5版本。第三个编号719是程序集的build号。如果公司每天都生成程序集，那么每天都应该递增这个build号。最后一个编号2指出当前build的修订次数。如果因为某个原因，公司某一天必须生成两次程序集（可能是为了修复一个造成其他什么事情都干不了的红毯bug），revision号就应该递增。
2，程序集中的三个版本号：
①AssemblyFileVersion
这个版本号存储在Win32版本资源中。它仅供参考，CLR既不检查，也不关心这个版本号。通常，可以选设置好版本号的major/minor部分，这是希望公众看到的版本号。然后，每生成一次就递增build和revision号（根据生成时的日期和时间）。但实情并非如此。在Windows资源管理器中能看到这个版本号。对客户系统进行故障诊断时，可根据它识别程序集的版本是多少
②AssemblyInfomationnalVersion
这个版本号也存储在Win32版本资源中，同样仅供参考。CLR既不检查，也不关心这个版本号。这个版本号的作用是指出包含该程序集的产品的版本。例如：产品的2.0版本可能包含几个程序集，其中一个程序集标记为版本1.0，为我他是新开发的，在产品的1.0版本中不存在。通常，可以设置这个版本号的major和minor部分来代表产品的公开版本号。以后每次打包所有程序集来生成完整产品，就递增build和revision部分
③AssemblyVersion
这个版本号存储在AssemblyDef清单元数据表中。CLR在绑定到强命名程序集时会用到它。这个版本号很重要，它唯一性地标识了程序集。开始开发程序集时，应该设置好major/minor/build/revistion部分。而且除非要开发程序集的下一个可部署版本，否则不应变动，如果程序集A引用了强命名的程序集B，程序集B的版本会嵌入程序集A的AssemblyRef表。这样一来，当CLR需要加载程序集B时，就准确地知道当初生成和测试的是程序集B的哪个版本。利用绑定重定向技术，可以让CLR加载一个不同的版本