Are there good reasons for letting AssemblyVersion and AssemblyFileVersion match?

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 AssemblyFileVersion on every build,
• change AssemblyVersion only on public interface or otherwise major changes,
• make sure that AssemblyVersion and A开发者_如何学运维ssemblyFileVersion share 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.

---

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.

---

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.

---

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.