I am running into an unusual issue with assembly loading. Let’s say we have Foo.dll which references FooInfra.dll version 1.0.0.0 that is strong name signed.
We are using an external executable to load Foo.dll and call MyMethod() within it. For some reason, when running the exe in a specific mode, let’s call it Mode A, MyMethod() succeeds to run even if FooInfra.dll version 2.0.0.0 is deployed by accident. If running it in “Mode B” we get the expected error that the correct assembly was not found.
My question: how is this possible? I thought with strong named assemblies, the correct version must be used. I already attached with windbg to make sure that it is not loading FooInfra.dll from a different place in Mode A, and it is not – it is really loading version 2.0.0.0.
Is it possible that in Mode A, the external executable loads the DLL explicitly, bypassing the strong name check when MyMethod runs, since the assembly is only loaded?
Any insight on the issue, or how to debug/diagnose would be greatly appreciated. Thanks!
You aren’t specifying how the load is differing in each case. Also – rather than windbg I’d use Fusion to log your assembly loading. It will show you what paths are being probed and you can see if it is completely ignoring the strong name in case 2.
Without more technical details beyond that provided its hard to say. If foo does have the reference (check in reflector) to the strong named assembly USING the strong name as well, Id expect it to fail but its possible there is documentation in however you are loading in mode A that by design it skips checks (again more detail required)
You are by any chance using the -Vr option are you?
http://www.lookout.net/2006/04/09/bypassing-strong-name-verification-for-a-net-assembly/