Are there good reasons for letting AssemblyVersion and AssemblyFileVersion match?

Question

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 AssemblyFileVersion 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.

Auspex

Answer 1

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.

Linker

I second this opinion - File Version is highly valuable across multiple builds, but between public releases. Generally you would never change the assembly version more than once between public releases, but from day to day, your testing department is just one example of needing a way to determine what build a particular DLL comes from... to be able to log descriptive issue reports in this case. Because (ideally) all of these builds (gearing up for a release) share the same assembly version, then file version is the right tool for differentiating them. – Baroda

Answer 2

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.

Denouement

Answer 3

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.

Lightner