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

Question

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

该规则检查 [AssemblyVersion] 匹配 [AssemblyFileVersion] 当两者都存在于程序集中时。一旦部署应用程序，两个属性中具有不同的版本号可能会造成混乱。

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

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

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

• 更新 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 Framework 本质上认为具有相同 AssemblyVersion 的两个程序集是可以互换的。

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

这可能会让普通开发人员感到困惑，因此制定了这一规则。

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