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

Gendarme的 AvoidAssemblyVersionMismatchRule 具有以下描述:



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

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

我不同意宪兵的规则。 之后，将无法使用类似于Microsoft使用的版本控制方案，即

在每个版本

上更新AssemblyFileVersion

仅在公共(public)界面或其他重大更改

上更改AssemblyVersion

确保AssemblyVersion和AssemblyFileVersion共享公共(public)前缀

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

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

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

最佳答案

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

AssemblyVersion更像是“整个应用程序的版本”，而FileVersion是单个文件的版本。如果您的应用程序具有多个出于各种原因而具有不同更新周期的程序集(例如，单独更新但需要主应用程序的特定主要版本的插件)，则可以为每个程序集提供不同的FileVersion，但是具有通用的AssemblyVersion。

另外，有时候，更新AssemblyVersion确实很不方便(例如，SharePoint Workflows和Web部件是PITA，因为他们希望指定的AssemblyVersion而进行更新)，因此FileVersion通常用作真实版本。

关于.net - 让AssemblyVersion和AssemblyFileVersion匹配有充分的理由吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2081658/