这篇文章中的一些好信息来自苏珊娜·库克在MSDN上的博客（发布于2003-05-30）：

何时更改文件/部件版本

首先，文件版本和部件版本不必重合彼此之间。我建议文件版本随建筑但是，不要每次构建都更改程序集版本你可以区分相同的两个版本文件请使用文件版本。决定何时更改程序集版本需要对构建类型进行一些讨论：运输和非运输。

非装运版本
通常，我建议在装运版本之间保持非装运程序集版本不变。这避免了版本导致的强命名程序集加载问题不匹配。有些人更喜欢使用发布者策略重定向新每个生成的程序集版本。我建议不要那样做然而，非装运构建：它并不能避免所有装载问题。例如，如果合作伙伴x复制了你的应用程序，他们可能不会知道安装发布者策略。然后，你的应用程序将被破坏它们，即使它在你的机器上运行得很好。

但是，如果在同一个应用程序上有不同的应用程序机器需要绑定到不同版本的程序集，我建议为这些生成提供不同的程序集版本，以便每个应用程序都可以使用正确的一个，而无需使用LoadFrom/等。

运输构建
至于更改运输构建的版本是否明智，取决于您希望绑定的方式为最终用户工作。您希望这些生成并排还是到位？这两个版本之间有很多变化吗？他们是会让一些顾客失望吗？你在乎它会打断他们吗你想强制用户使用你的重要更新）？如果是，您应考虑递增程序集版本。但是，话说回来，考虑到这样做的次数太多可能会损坏用户的磁盘具有过时的程序集。

更改程序集版本时
若要将硬编码版本更改为新版本，我建议将变量设置为该版本在头文件中，并将源中的硬编码替换为变量然后，在构建过程中运行预处理器，将正确的版本。我建议在发货后立即更改版本，之前没有，这样就有更多的时间来捕捉由于改变

定义版本控制的一种方法是为每个部分赋予语义：

• 当与新继电器的兼容性中断时，从N.x转到N+1.0
• 当添加了不会破坏兼容性的新功能时，从N.M转到N.M+1
• 添加错误修复后，从N.M.X转到N.M.X+1

以上只是一个例子——您希望定义对您有意义的规则。但是，用户只需查看版本就可以快速判断是否存在不兼容，这是非常好的。

哦，别忘了公布你制定的规则，让人们知道该期待什么。

语义版本控制有一套关于如何应用（以及何时应用）的指导方针和规则。遵循起来非常简单，而且很有效。

http://semver.org/

我建议的第一件事是熟悉Assembly版本和File版本之间的差异。不幸的是，当涉及到AssemblyInfo文件时，.NET倾向于将这些文件视为相同的文件，因为它通常只放置AssemblyVersion，并允许FileVersion默认为相同的值。

既然你说这是一个共享程序集，我假设你的意思是它是在二进制级别上共享的（而不是通过将项目包含在各种解决方案中）。如果是这种情况，您需要非常慎重地更改程序集版本，因为这是.NET用来对程序集进行强命名（允许您将其放入GAC）并构成"程序集全名"的方法。当程序集版本更改时，它可以对使用它的应用程序进行中断更改，而无需在app.config文件中添加程序集重定向项。

至于命名，我认为这取决于您公司的命名规则（如果有的话）和库的用途。对于exmaple，如果这个库提供的"核心"（或系统级）功能不特定于任何特定的产品或业务线，您可以将其命名为：

CompanyName.Framework.Core 

如果它是一个更大的库的一部分，或者只是

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

至于何时增加版本号，这仍然是相当主观的，取决于您认为构建号的每个部分要表示什么。默认的Microsoft方案是Major.Minor.Build.Revision，但这并不意味着你不能提出自己的定义。最重要的是在你的战略中保持一致，并确保定义和规则在你的所有产品中都有意义。

在我见过的几乎每一个版本方案中，前两个部分都是Major.Minor。当出现大的更改和/或中断更改时，主版本号通常会递增，而次版本号通常递增，表示发生了更改的内容不是中断更改。另外两个数字要主观得多，可以是"版本"（通常是一个连续日期值或一个每天都在变化的顺序更新数字的倍数）和"修订"或补丁号。我也看到过它们的反转（给出Major.Minor.Revision.Build），其中Build是自动构建系统中的一个按顺序递增的数字。

请记住，导出程序集时，程序集的主要版本和次要版本将用作类型库版本号。

最后，查看其中一些资源以获取更多信息：

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx