Question

I am working on a Qt DLL that is used as a plugin for a large application. This DLL depends on other DLLs that are sadly not located in the same folder and hence will only load if the current working directory has been set correctly (which the large application does prior to calling LoadLibrary on the DLL). I have no control over this behaviour.

I have been asked to add a simple COM object to this plugin which I have done but I now have the problem that the DLL cannot be registered or used by a 3rd-party application unless the current working directory is set correctly – because any LoadLibrary calls on the plugin fail due to the missing dependencies. Obviously I have no control over the current working directory used by 3rd-party apps and at this stage I am not allowed to modify the PATH to ensure the dependencies can be found.

I have tried using /DELAYLOAD for the dependent DLLs but this fails with ‘cannot delay-load foo.dll due to import of data symbol…’ errors. Again, I cannot easily change the way these dependent DLLs are used.

Currently I think the only solution is to move the COM object into a stand-alone DLL that doesn’t depend on anything else but I am under pressure to find a solution and leave the COM object in the plugin DLL. I can’t see how this is possible so I thought I’d see if anyone else has any ideas. Some form of system-wide SetDllDirectory call would help or some registry hack that could set the working directory when a 3rd-party app calls LoadLibrary on my plugin.

Answer 1

IMO separating the COM object into a separate .dll is the cleanest solution – anyone would expect an in-proc COM server to be registered by using regsvr32 and that requires no fancy dependencies in that COM server.