10

宪兵有AvoidAssemblyVersionMismatchRule以下描述：

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

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

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

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

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

而且我认为这种版本控制方案是设计原因，它可以首先区分AssemblyVersion和AssemblyFileVersion。

我想不出为什么强制两个程序集属性相等是一个好习惯的原因，但也许你可以！我会对你的意见感兴趣。

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

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

4

3 回答 3

9

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

AssemblyVersion 更像是“整个应用程序的版本”，而 FileVersion 是单个文件的版本。如果您的应用程序有多个具有不同更新周期的程序集，无论出于何种原因（例如，单独更新但需要主应用程序的特定主要版本的插件），那么您可以为每个程序集赋予不同的 FileVersion 但具有共同的 AssemblyVersion。

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

于 2010-01-17T16:40:11.710 回答
4

同意，这是一个愚蠢的规则。当您关注强命名程序集时，您无法为它部署一个插入式错误修复更新。如果您实际上必须更改 [AssemblyVersion]，则几乎没有理由不使它们相同。修复错误时，也许您不应该使用该工具。讽刺。

于 2010-01-17T16:35:35.010 回答
0

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

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

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

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

于 2010-01-18T08:27:37.823 回答