Domanda

IIS loads legacy ISAPI extension and IIS module, both use DLL with same name, however these DLLs are different (linked against different versions of thirdparties). So far there should be no problem, each component (extension and module) reside in their own folders, each one with its own version of DLL, but when IIS starts the worker process and extension and module got loaded somehow the extension tries to load the DLL from the module's folder. I've inspected the module's code and found use of SetDllDirectory which affects the whole process. Voila, this is the problem, I said. after getting rid of this call (replaced with LoadLibraryEx with DLL search flags which suites my needs) the problem persisted. Finally I found myself with giving unique names to both of these DLLs, which obviously (or not) solves the problem. However it is not clean and elegant solution. Is anyone has any idea why IIS exhibits such a strange behaviour?

Running Win2008, IIS7.5, ISAPI extension - native, C++, VC2010, IIS Module - native, C++, VS2010, above problematic DLL - C++/CLI, linked with .NET3.5 third party assemblies. everything is x64

È stato utile?

Soluzione

"You can’t have two “classic” DLLs of the same name in the same process unless they’ve been engineered to support SxS" It correlates with what was said here: Could we have 2 DLLs with the same name being loaded in one process

EDIT001: 5 years later :) The root cause of this is the way the IIS loads stuff. When the worker process starts the IIS module stuff gets loaded in any case, and then the ISAPI. So, in case both use same DLLs (for example these two have common infrastructure implementation) the IIS module will get loaded first and the ISAPI will have to use DLLs loaded by module. So, you better keep your shared DLL for both IIS Module and ISAPI of the same version.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top