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.

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.