.net 让AssemblyVersion和AssemblyFileVersion匹配有充分的理由吗？

具有具有以下描述的：

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

例如，此规则将在具有以下属性的Microsoft的

System.dll

上发出警告：

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

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

• 在每次生成时更新

  AssemblyFileVersion

• 仅在公共界面上更改

  AssemblyVersion

  或其他重大更改
• 确保

  AssemblyVersion

  和

  AssemblyFileVersion

  共享一个公共前缀

我认为，这个版本控制方案是一开始就可以区分

AssemblyVersion

和

AssemblyFileVersion

的设计原因

我想不出为什么强制两个程序集属性相等是一个好的做法，但也许您可以我想听听你的意见。

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

当和都存在于程序集中时，此规则检查它们是否具有公共的非空前缀

---

同意，这是一个愚蠢的规则。当您遵循强名称程序集时，无法为其部署drop-in bug fix更新。如果您确实需要更改[AssemblyVersion]，那么没有其他理由不将它们更改为相同的版本。也许你不应该在修复bug时使用这个工具。具有讽刺意味。

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

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

---

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

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

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

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

---

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

我支持这一观点-文件版本在多个版本之间，但在公共发布之间，具有很高的价值。一般来说，在公共版本之间，您永远不会多次更改程序集版本，但每天，您的测试部门只是需要一种方法来确定特定DLL的构建来源的一个例子。。。在这种情况下，能够记录描述性问题报告。因为（理想情况下）所有这些构建（准备发布）共享相同的程序集版本，所以文件版本是区分它们的正确工具。