让AssemblyVersion和AssemblyFileVersion匹配是否有很好的理由？

Gendarme具有与以下描述的AvoidAssemblyVersionMismatchRule：让AssemblyVersion和AssemblyFileVersion匹配是否有很好的理由？

此规则检查该[AssemblyVersion]的[AssemblyFileVersion]匹配时两者都存在的组件的内部。一旦部署了应用程序，在两个属性中使用不同的版本号都会造成混淆。

例如，该规则将警告微软System.dll它具有以下属性：

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

我不同意宪兵统治。跟随它，就不可能给你用类似于微软使用的一个版本方案，即

更新AssemblyFileVersion在每次构建，
只在公共接口或以其他方式发生重大变化的变化AssemblyVersion，
确保AssemblyVersion和AssemblyFileVersion有着共同的前缀，

，我觉得这个版本方案是设计它之所以成为可能，以首先区分AssemblyVersion和AssemblyFileVersion。

我不能拿出一个强制两个组件属性相同的理由是一个好习惯，但也许你可以！ 我会对你的意见感兴趣。

如果确实没有很好的理由，我很快就会建议宪兵开发商规则更改为

此规则会检查[AssemblyVersion]和[AssemblyFileVersion]有一个共同的，非空前缀时两者都存在于组件中。

来源

2010-01-17 Christian

意见==社区维基 – 2010-01-17 16:36:29

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

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

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

来源

2010-01-17 16:40:11

我第二个意见 - 文件版本是跨多个版本，但公开发布之间非常有价值。一般来说，你永远不会在公共版本之间多次改变程序集版本，但是日常的测试部门只是需要一种方法来确定一个特定的DLL来自哪个版本的一个例子......为了能够记录描述在这种情况下发布报告。由于（理想情况下）所有这些构建（为发布而加速）共享相同的程序集版本，因此文件版本是区分它们的正确工具。 – Adam 2011-06-19 22:52:12

同意，这是一个愚蠢的规则。当您遵循它时，您无法为强壮的命名程序集部署一个嵌入式错误修复程序更新。除非你真的需要改变[AssemblyVersion]，否则没有什么理由让它们不变。也许你在修复错误时不应该使用该工具。具有讽刺意味的。

来源

2010-01-17 16:35:35

我认为这个规则在很多情况下都是有意义的，因为.NET框架基本上认为两个具有相同AssemblyVersion的程序集是可以互换的。

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

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

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

来源

2010-01-18 08:27:37 Joe

让AssemblyVersion和AssemblyFileVersion匹配是否有很好的理由？

回答

相关问题