What does .NET mean by 'primary' when choosing between conflict dll reference?

Question

I was having some trouble with version of dll present in the manifest and the actual version present in the build folder. Changing the build option to detailed gave this 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=31bf3856ad364e35".

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

In the second section it says that particular version was choosen as it was primary.

What's the meaning of primary?

Regards.

Answer 1

You are asking MSBuild to solve a DLL Hell problem. It must copy Microsoft.Practices.EnterpriseLibrary.Common.dll to your build output directory so you can run your program. But you reference two different versions of it. That cannot work, one will overwrite the other and its a crap-shoot who will win.

So it needs to guess which one is more "important". One of your assemblies has a "primary" dependency, it directly references types inside Microsoft.Practices.EnterpriseLibrary.Common.dll. Another one of your assemblies has a indirect dependency, it uses an assembly that was built with version 6.0.0.0 of asssembly. Forced to guess, MSBuild assumes that the primary one is more important.

It is just a guess. It might work, you need a <BindingRedirect> in the app.exe.config file to map the request for the 6.0.0.0 version of the assembly to the 5.0.505.0 version since the 6.0.0.0 version will not be available. Having a major version mismatch is never good news, a TypeLoadException or MissingMethodException at runtime should not surprise you. If that doesn't work then installing these assemblies in the GAC might be a workaround, no need to copy the DLLs that way. Of course the real fix is to only ever have one specific dependency.