Which assembly executes the code?

2
votes

I'm working on a .net project, which is using third party .net DLLs. Some of this DLLs are using common DLLs (e.g. Microsoft.Practices.EnterpriseLibrary.Logging). Now we want to use the same common DLLs in a newer version. We are not allowed to use the GAC (politics).

We have separated the parts in different directories.

Third party \ Third party.dll
              old common (Microsoft.Practices.EnterpriseLibrary.Logging.dll)
Our libs \ our lib.dll
              new common (Microsoft.Practices.EnterpriseLibrary.Logging.dll)

Surprise, Surprise, it did not work. In our dll an error is thrown saying, some option is not valid. Yes, I did not find it in the old common, but in the new. So, I guess, the wrong executable was taken.

In Visual Studio (2015) we have enabled the "Spezific Version" in the reference, and in the Debug / module windows, both DLLs are loaded.

Edit: All Dlls have strong names.

How do I determine which DLL was executed (stepping with F11 just jump to the catch block)? How do I force using the correct DLL?

(The architecture loads first the third party DLL, then our own dll. This is not changeable without a few years rewriting...)

1
c#.netdll
Have only one DLL, and use assembly binding redirects in the configuration to explicitly point to the latest version only. If the loads fail, you can enable assembly binding logging to see what's up. – Jeroen Mostert
Does it help if you set the reference to a specific version? – KMoussa
No. The error still occurs. – Ralph Erdt
I'm not sure that I fully understand your situation, but it sounds like this may be a case for Extern alias. see: Extern alias walkthrough – TnTinMn
Hello. I've tested the last two days, but I did not catch or work around the error. I'll now ignore this for the moment. Maybe in a week or two I got an Idea. Tanks for the help and ideas. – Ralph Erdt

1 Answers

0
votes

You can use assembly binding redirects and hope the universe doesn't break (there's no guarantee the newer DLL is backward compatible) or you can strong name the dlls.

Why? .NET generally does not allow you to load the "same" assembly more than once in the same AppDomain, unless it is strong-named. What's strong naming? It is a form of identity and digital signing that consists of:

  1. Assembly filename
  2. Assembly version
  3. Assembly culture
  4. Assembly public key

When it's strong-named, both dlls run side-by-side in the same AppDomain within the same process with perfect backward compatibility.

Alternatively if you don't want to use strong-naming (because many files may require signing) or binding redirects, you can always create additional AppDomains and load a version of the dlls into each domain.

Though it gets around the problem of fiddling with files, it does require considerable rework of the rest of the app making it an arguably bad choice at this point in your development.

EDIT: I see now you are using strong names on both.

How do I force using the correct DLL

To distinguish between the two types in the exact same namespace, you might have to create an alias for the newer assembly in your dll reference. Tell me more...