是否有充分的理由让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 Workflows和Web部件是PITA要更新,因为它们期望指定的AssemblyVersion),因此FileVersion通常用作真实版本.