I have the following scenario:
An executable application can be customized by dlls and multiple of these customizations can be started in parallel. For common tasks these dlls can use dynamically linked open source libraries like OpenSSL (libssl.lib, libcrypto.lib which are retrieving the modules libssl-1_1-x64.dll and libcrypto-1_1-x64.dll).
In order to retrieve the desired library modules, they are linked with the /delayload option. However if the libraries have the same name (e.g. since they are different versions of the same library) the first LoadLibrary
will do the binding for all libraries.
In a more abstract description, the following scenario will retrieve lib1\lib.dll and lib2\lib.dll, but it will always call the functionality from lib1\lib.dll, since this module was retrieved first.
prog.exe - loads dll1.dll - linked /delayload lib1\lib.lib - requires lib1\lib.dll - loads dll2.dll - linked /delayload lib2\lib.lib - required lib2\lib.dll
Is there any way to influence the binding for the dll2.dll instead of working with GetProcAddress
for the retrieved dll?
Yes, there is. You can use a separate Activation Context for each load, either manually by using the Activation Context API directly, or by using manifests.
See How can I specify that my DLL should resolve a DLL dependency from the same directory that the DLL is in?: