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

Question

Gendarme有AvoidAssemblyVersionMismatchRule，其中包含以下说明：

  

当规则中存在两者时，此规则会检查[AssemblyVersion]是否与[AssemblyFileVersion]匹配。一旦部署了应用程序，两个属性中的版本号不同可能会造成混淆。

例如，此规则会警告具有以下属性的Microsoft System.dll：

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

我不同意Gendarme的规则。跟随它会使您无法使用类似于Microsoft使用的版本控制方案，即

• 在每次构建时更新AssemblyFileVersion，
• 仅在公共界面或其他重大更改上更改AssemblyVersion，
• 确保AssemblyVersion和AssemblyFileVersion共享一个共同的前缀

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

我无法想出为什么强制两个装配属性相等是一个好习惯，但也许你可以！ 我会对您的意见感兴趣。

如果确实没有充分理由，我很快会建议Gendarme开发人员将规则更改为

  

此规则会检查[AssemblyVersion]和[AssemblyFileVersion] 在程序集中是否存在共有的非空前缀。

Answer 1

同意，如果它们匹配，则不需要两个不同的属性开始！但正如规则所说：这可能令人困惑。

AssemblyVersion更像是“整个应用程序的版本”，而FileVersion是单个文件的版本。如果您的应用程序有多个程序集由于任何原因而具有不同的更新周期（例如，单独更新但需要主应用程序的特定主要版本的插件），那么您可以为每个程序集提供不同的FileVersion但具有通用的AssemblyVersion。 / p>

此外，有时，更新AssemblyVersion非常不方便（例如，SharePoint Workflows和Web部件是PITA要更新，因为它们需要指定的AssemblyVersion），因此FileVersion通常用作真实版本。

Answer 2

同意，这是一个愚蠢的规则。当您遵循它时，您无法为强命名程序集部署插入式错误修复更新。如果您真的需要更改[AssemblyVersion]，则没有其他理由不使它们相同。也许你在修复bug时不应该使用该工具。具有讽刺意味的。

Answer 3

我认为该规则在许多场景中都有意义，因为.NET Framework基本上认为具有相同AssemblyVersion的两个程序集是可互换的。

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

这对于普通开发者来说可能会造成混淆，因此也就是规则。

当然，如果您知道自己在做什么并理解权衡取舍，那么您可以忽略该规则。