How the assembly version matching works exactly?

Question

Let's say I have assemblies in GAC with versions, 1.1.1.5, 1.1.5.1, 1.1.6.2, 1.2.1.1 and 2.1.2.1. My application have a reference of 1.1.3.0 version. Which assembly will be matched at runtime? and what are the actual rules for assembly matching?

Answer 1

If your reference requires a specific version, by default, it will fail on assembly load, as that version doesn't exist.

This can be configured, however, via Assembly Binding Redirection. There are various options of what will happen here, including:

• The reference can say that it doesn't care about versioning, in which case the newest is loaded.
• You can configure your application in a way that you specify how to redirect the binding.
• The assembly in the GAC can be setup with a publisher policy that specifies how to handle this.

Answer 2

Which assembly will be matched at runtime?

None will be matched, your program will bomb.

The documentation for the Version class talks generically about how you pick version numbers. And yes, you normally consider a change in the build number to be a non-breaking change. And a change in the revision to be low risk. Things you consider when you pick an [AssemblyFileVersion].

However, the default CLR policy does not implement this kind of interpretation of the [AssemblyVersion], it insists on an exact match. It is only happy when it find the exact same DLL that you compiled your program with. This is not normally difficult to ensure. You can override this policy and make it weaker, although you should always think twice about that. There is a very long history of well intended minor changes in source code that just did not pan out that well in practice. Something that Microsoft knows too well, having to maintain code that lasts for decades. The default counter-measures against DLL Hell in the CLR are hard as a rock. As they should be. Ratcheting it down up to you.