上一节指出可以将几个版本号应用于一个程序集。所有这些版本号都具有相同的格式，每个都由4个以句点分隔的部分构成，如表2-5所示。
表2-5 版本号格式
| major(主版本号) | minor(次版本号) | build(内部版本号) | revision(修订号) | |
| 示例 | 2 | 5 | 719 | 2 |
表2-5展示了一个示例版本号：2.5.719.2。前两个编号构成了公众对一个版本的理解。公众会将这个例子看成是程序集的2.5版本。第三个编号719是程序集的build号。如果公司每天都要生成程序集，那么每天都应该递增这个build号。最后一个2指出当前build的修订次数。如果因为某个原因，公司某一天必须生成两次程序集（可能是为了修复一个重大bug），revision号就应该递增。
Microsoft使用的就是这个版本编号方案，而且强烈建议你也使用它。CLR未来的版本会为程序集新版本的加载提供更好的支持，而且假如新版本会妨碍一个现有的应用程序，还允许方便地还原到之前的一个版本。为了实现这种程序的版本支持，CLR希望修正了一处或多处bug的程序集具有和修正之前相同的major/minor版本号，但build/revision号要反映出这是包含了bug修复的一个维护（servicing）版本。加载一个程序集时，CLR会自动查找与请求的程序集的major/minor版本相匹配的一个已安装的最新维护版本。
前面说过，一个程序有三个版本号和它关联。这会使局面复杂化，并造成大量混淆。所以，有必要解释一下每个版本号的用途以及它们的正确用法：
- AssemblyFileVersion 这个版本号存储在Win32版本资源中。它仅供参考，CLR既不会检查，也不会关心这个版本号。通常，可以先设置好版本号的major/minor部分，这是希望公众看到的版本号。然后，每进行一次生成，就递增build和revision部分。理想情况是Microsoft的工具（比如CSC.exe或者AL.exe）能自动更新build和revision号（根据生成时的日期和时间）。但实情并非如此。使用Windows资源管理器可以看到这个版本号。对一个客户的系统进行故障诊断时，它通常用于标识程序集的一个特定的版本。
- AssebmlyInformationVersion 这个版本号也存储在Win32版本资源中，且同样仅供参考。CLR既不会检查它，也不会关心它。这个版本号的作用是指出包含该程序集的一个产品的版本。例如，产品的2.0版本可能包含几个程序集，其中一个程序集被标记为版本1.0，因为它是一个新开发的程序集，在产品的1.0版本中是不存在的。通常，可以设置这个版本号的major/minor部分来代表产品的公开版本号。然后，每次打包所有程序集来生成一个完整的产品，就递增build/revision部分。
- AssebmlyVersion 这个版本号存储在AssemblyDef清单元数据表中。CLR在绑定到强命名程序集时（第3章讨论），会使用这个版本号。这个版本号非常重要，它唯一地标识了一个程序集。着手开发一个程序集时，应设好major/minor/build/revision部分。而且除非着手开发程序集的下一个可部署的版本，否则不应该更改它们。生成一个程序集时，引用的程序集版本号会嵌入AssemblyRef表的记录项中。这意味着一个程序集将与所引用的程序集的一个特定的版本紧密绑定到一起。