是否有充分的理由让AssemblyVersion和AssemblyFileVersion相匹配？

Question

宪兵有一个具有以下描述的AvoidAssemblyVersionMismatchRule：

此规则检查当[AssemblyVersion]和[AssemblyFileVersion]都存在于程序集中时，两者是否匹配。部署应用程序后，在这两个属性中拥有不同的版本号可能会让人感到困惑。

例如，此规则将警告微软的System.dll，它具有以下属性：

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]

我不同意宪兵队的规则。遵循规则将使您无法使用类似于微软使用的版本控制方案，即

• 更新每个版本的AssemblyFileVersion，
• 仅在公共接口或其他重大更改上更改AssemblyVersion，
• 确保AssemblyVersion和AssemblyFileVersion共享一个共同的前缀，

我认为这个版本控制方案是为什么能够首先区分AssemblyVersion和AssemblyFileVersion的设计原因。

我想不出为什么强迫两个程序集属性相等是一个很好的做法，但也许你可以！，我会对你的观点感兴趣。

如果确实没有很好的理由，我将很快建议宪兵开发人员将规则改为

此规则检查[AssemblyVersion]和[AssemblyFileVersion] 是否具有公共的、非空的前缀，而两者都存在于程序集中。

Answer 1

同意，如果他们应该匹配，那么就不需要有两个不同的属性开始！但正如规则所言:这可能会令人困惑。

AssemblyVersion更像是“整个应用程序的版本”，而FileVersion则是单个文件的版本。如果您的应用程序有多个程序集，这些程序集具有不同的更新周期(例如，单独更新但需要主应用程序的特定主要版本的插件)，那么您可以给每个程序集一个不同的FileVersion，但是有一个公共的AssemblyVersion。

而且，有时候，更新AssemblyVersion非常不方便(例如，SharePoint工作流和Web部件是一个需要更新的PITA，因为它们需要一个指定的AssemblyVersion)，因此通常使用FileVersion作为真正的版本。

Answer 2

同意，这是个愚蠢的规则。跟踪强命名程序集时，无法为强命名程序集部署插入错误修复更新。否则，如果您必须更改AssemblyVersion，则很少有理由不使它们相同。也许你不应该在修复错误的时候使用那个工具。很讽刺。

Answer 3

我认为这个规则在很多情况下都是有意义的，因为.NET框架本质上认为两个具有相同AssemblyVersion的程序集是可互换的。

因此，例如，下载缓存中的旧版本不会被仅在AssemblyFileVersion中不同的新版本自动覆盖。

对于普通的开发人员来说，这可能会让他们感到困惑，因此这是一条规则。

当然，如果你知道你在做什么，并且理解这种权衡，你可以忽略这个规则。