Can different versions of DLL be loaded in same ap

2020-07-09 10:22发布

问题:

My application uses one version of library (a.dll), I am using another DLL(b.dll) which in-turn uses older version of the same library (a.dll) that i use. I am building the application by embedding a manifest file. The DLL i use is also using a embedded manifest file. I am having both the versions of the library in my WinSXS folder. My application is not able to load the appropriate versions of DLLs.

Will having a separate manifest file (not embedding into DLL) help resolving the problem? What is the work around?

回答1:

Your situation is exactly the situation WinSxS is supposed to solve. It should be working.

Either: The manifest files are pointing to the same version, or one of the manifest files is not embedded properly, or

The shared assembly in WinSxS was installed with a configuration policy that automatically redirects requests for v1.0 to v1.1


Some clarifications are needed: App.exe and b.dll are implicitly linked against a.dll? Or do they load it via LoadLibrary.

If B.DLL loads A.DLL explicitly using LoadLibrary then you need to add ISOLATION_AWARE_ENABLED to your pre-processor definitions to ensure that LoadLibrary calls made by B.DLL look in the correct activation context. Otherwise they will be made in the context of the default activation context which was created by the EXE's manifest.



回答2:

It will depend on what the duplicated DLLs do and if their versions are compatible. (e.g. Do they both access shared objects in memory? If so, there's a good chance something will blow up.)

It will also depend on how those two same-named DLLs are loaded. If it's anything other than an explicit LoadLibrary with a full path then things probably will not work. There's an ongoing discussion of this here: Determine the loaded path for DLLs

In general, it might work if you're lucky. The fact it may go catastrophically wrong is a good reason to avoid the issue entirely, if you can. (In the worst case, you could host one of the modules in another process and proxy all the calls to it. Ideally, just be able to use the same DLL version in both modules.)