My project is a plug-in (Windows DLL) that is loaded by a host executable not under my control. My DLL wants to load some additional libs. I do this with private assemblies; there's a great answer at how can a Win32 App plugin load its DLL in its own directory for how to do this. But if I add /delayload dependentlib.dll
on the main DLL's link line to avoid loading the assembly til it's needed (I have to do this for various reasons), Windows no longer searches my private assemblies -- seems like it ignores the manifest I compiled in. Instead it looks for the delay-loaded DLL in the usual search path. (I use sysinternals procmon to check this.)
Is this a known bug, or is there any other way to delay-load an assembly? I'd rather not go the LoadLibrary + GetProcAddress route where I have to know all the symbols I care about in the dependent lib.
Your problem here is, when the first call to a delay loaded function is made, the applications default activation context is the current context.
What you need to do is create an activation context: CreateActCtx pointing at your own manifest (hinstance+resource id is possible I think).
Then, wrap all, or at least the very first, call to the dll with ActivateActCtx (and the corresponding deactivate function) to ensure the correct assemblies are searched.
In theory you could just embed the code to activate the appropriate context in the delayload helper function.