The located assembly's manifest definition with name xxx.dll does not match the assembly reference

  • Article

This is a very common Assembly.Load failure exception text. In fusion terminology, this is called Ref-Def-Mismatch. This exception is thrown when fusion finds an assembly that does not match what you are looking for. A very common mismatch is version number. An example is, you asks for version 1.0.0.0, but version 2.0.0.0 is found. (keep in mind that for simply named assemblies, version number is ignored. So we are really talking about strongly named assemblies here.)

The only time this exception will be thrown is when the mismatched assembly is in your appbase. Fusion will probe GAC first. If the assembly is not found in GAC, fusion will probe your appbase. If fusion finds an assembly that matches the simple name, but has mismatch on other part of the assembly name, this exception will be thrown. Say you call Assembly.Load(”MyAsm,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=0123456789abcdef”, and fusion finds MyAsm.dll in your appbase, but its version is 2.0.0.0, fusion will thrown this exception.

An interesting question is why can't fusion just keep probing. Remember fusion will probe a couple of places before it stops. If the first one is mis-matched, maybe later fusion can find another match?

There are several reasons.

1. It is very rare that people will have several assemblies with the same file name in the probing path. So keep probing usually won't help anyone.
2. Because of 1, you get unnecessary penalty if fusion keeps probing. This is especially bad for http bind.
3. Most of the time this exception is due to deployment error. So throwing early will help catch deployment error.

There are more reasons. But I'll show them later when I get time to show some binding design decision.

Another interesting observation on this is for dependencies of LoadFrom assemblies. For dependencies of LoadFrom assemblies, we will probe the appbase, then the parent assembly's directory. If a mismatch assembly is found in appbase, it does not mean a matching assembly won't be found in parent assembly's directory.

In v1/v1.1, we treat this case the same as normal probing, and throw on the first mismatch. In Whidbey, we take a DCR to keep probing the parent assembly's directory. (DCR stands for Design Change Request. It usually means change of behavior)