让 AssemblyVersion 和 AssemblyFileVersion 匹配是否有充分的理由？
宪兵有一个AvoidAssemblyVersionMismatchRule 具有以下描述：
此规则检查
[AssemblyVersion]匹配[ AssemblyFileVersion]当两者都存在于程序集中时。一旦部署应用程序，两个属性中具有不同的版本号可能会造成混乱。
例如，此规则将对具有以下属性的 Microsoft System.dll 发出警告：
[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]
我不同意 Gendarme 的规则。 遵循该规则将使您无法使用版本控制方案与 Microsoft 使用的类似，即
- 在每次构建时更新
AssemblyFileVersion， - 仅在公共接口或其他重大更改上更改
AssemblyVersion， - 确保
AssemblyVersioncode> 和AssemblyFileVersion共享一个共同的前缀，
我认为这种版本控制方案是可以区分 AssemblyVersion 和 AssemblyFileVersion 的设计原因> 首先。
我无法想出为什么强制两个程序集属性相等是一个好的做法，但也许你可以！ 我对你的意见很感兴趣。
如果确实没有充分的理由，我很快就会建议宪兵开发者将规则更改为
此规则检查
[AssemblyVersion]和[AssemblyFileVersion ]当两者都存在于程序集中时，具有共同的非空前缀。
Gendarme has an AvoidAssemblyVersionMismatchRule with the following description:
This rule checks that the
[AssemblyVersion]matches the[AssemblyFileVersion]when both are present inside an assembly. Having different version numbers in both attributes can be confusing once the application is deployed.
For example, this rule would warn on Microsoft's System.dll which has the following attributes:
[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]
I disagree with Gendarme's rule. Following it would make it impossible to you use a versioning scheme similar to the one used by Microsoft, that is
- update
AssemblyFileVersionon every build, - change
AssemblyVersiononly on public interface or otherwise major changes, - make sure that
AssemblyVersionandAssemblyFileVersionshare a common prefix,
and I think this versioning scheme is the design reason why it was made possible to differentiate between AssemblyVersion and AssemblyFileVersion in the first place.
I cannot come up with a reason why forcing both assembly attributes to be equal is a good practice, but maybe you can! I would be interested in your opinions.
If indeed there is no good reason, I will soon suggest the Gendarme developers to change the rule to
This rule checks that the
[AssemblyVersion]and[AssemblyFileVersion]have a common, non-empty prefix when both are present inside an assembly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
同意，如果它们应该匹配，那么一开始就不需要有两个不同的属性！但正如规则所说：这可能会令人困惑。
AssemblyVersion 更像是“整个应用程序的版本”，而 FileVersion 是单个文件的版本。如果您的应用程序有多个程序集，无论出于何种原因，这些程序集具有不同的更新周期（例如，单独更新但需要主应用程序的特定主要版本的插件），那么您可以为每个程序集提供不同的文件版本，但具有通用的程序集版本。
另外，有时，更新AssemblyVersion确实很不方便（例如，SharePoint工作流和Web部件是一个需要更新的PITA，因为它们需要指定的AssemblyVersion），因此FileVersion通常被用作真实版本。
Agree, if they should match then there wouldn't need to be two different attributes to begin with! But as the rule says: It could be confusing.
AssemblyVersion is more like "The version of your whole application" while FileVersion is the version of an individual file. If your Application has multiple assemblies that have different Update Cycles for whatever reason (e.g., Plugins that are updated separately but that require a specific major release of the main application), then you could give each a different FileVersion but have a common AssemblyVersion.
Also, sometimes, it's really inconvenient to update the AssemblyVersion (e.g., SharePoint Workflows and Web Parts are a PITA to update because they expect a specified AssemblyVersion), so there the FileVersion is often used as the real version.
同意，这是一个愚蠢的规则。当您遵循强命名程序集时，无法为其部署嵌入式错误修复更新。如果您确实必须更改 [AssemblyVersion]，则没有什么理由不使它们相同。也许您在修复错误时不应该使用该工具。讽刺的是。
Agreed, this is a silly rule. You could not deploy a drop-in bug fix update for a strong named assembly when you follow it. There is otherwise few reasons not to make them the same if you actually have to change the [AssemblyVersion]. Maybe you're not supposed to use that tool when you fix bugs. Ironic.
我认为该规则在许多情况下都有意义，因为 .NET Framework 本质上认为具有相同 AssemblyVersion 的两个程序集是可以互换的。
因此，例如，下载缓存中的旧版本不会自动被仅 AssemblyFileVersion 不同的新版本覆盖。
这可能会让普通开发人员感到困惑，因此制定了这一规则。
当然，如果您知道自己在做什么并了解权衡，则可以忽略该规则。
I think the rule makes sense in many scenarios, since the .NET Framework essentially considers two assemblies with the same AssemblyVersion to be interchangeable.
So, for example, an old version is in the Download Cache will not be automatically overwritten by a new version differing only in AssemblyFileVersion.
This can be confusing for the average developer, hence the rule.
Of course, if you know what you're doing and understand the trade-offs, you can ignore the rule.