What does .NET mean when "primary" when choosing between a link to a dll?

Question

I am having problems with the dll version present in the manifest and the actual version present in the build folder. Changing the assembly option for a detailed description gave the following information:

There was a conflict between "Microsoft.Practices.EnterpriseLibrary.Common, Version = 5.0.505.0, Culture = Neutral, PublicKeyToken = 31bf3856ad364e35" and "Microsoft.Practices.EnterpriseLibrary.Common, Version = 6.0.0.0, Culture = Neutral, PublicKeyToken = 31bf3556ad .

"Microsoft.Practices.EnterpriseLibrary.Common, Version = 5.0.505.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" was chosen because it was primary and "Microsoft.Practices.EnterpriseLibrary.Common, Version = 6.0.0.0, Culture = neutral , PublicKeyToken = 31bf3856ad364e35 "was not.

The second section says that a particular version was chosen as it was the primary one.

What does primary matter?

Sincerely.

Answer 1

You are asking MSBuild to solve the Hell DLL problem. It should copy the Microsoft.Practices.EnterpriseLibrary.Common.dll file to your output directory so that you can run your program. But you are referring to two different versions. It won’t work, one will rewrite the other and its shit-shoot, which will win.

Therefore, you need to guess which one is more "important". One of your assemblies has a "main" dependency; it directly refers to types inside Microsoft.Practices.EnterpriseLibrary.Common.dll. Another of your assemblies has an indirect dependency; it uses the assembly created with version 6.0.0.0 asssembly. Forced to guess, MSBuild suggests that core is more important.

This is just an assumption. This may work, you will need a <BindingRedirect> in the app.exe.config file to map the build version 6.0.0.0 request to version 5.0.505.0, since version 6.0.0.0 will not be available. Low version mismatch is never good news; a TypeLoadException or MissingMethodException exception at run time should not surprise you. If this does not work, then installing these assemblies in the GAC may be a workaround; there is no need to copy the DLL in this way. Of course, the real solution is to have only one specific dependency.