Options for changing Dll search part when loading plugin on Windows

We've built a VST plugin that depends on several other dll's that we supply with the plugin installer. To make sure that our plugin picks up the right dll's, we have modified the VSTPluginMain (for Win32 only) in juce_VST_Wrapper.cpp like this:

    extern "C" __declspec (dllexport) AEffect* VSTPluginMain (audioMasterCallback audioMaster)
      char oldPath[1024];
      getPreviousPath(oldPath, 1024);
      AEffect* effect = pluginEntryPoint (audioMaster);
      return effect;

where getPreviousPath and setHadronPath contain calls to GetDllDirectoryA and SetDllDirectoryA respectively.

This works really well, but I just wonder if there is a smarter way of doing this, and in particular one that doesn't involve modifying the Juce source.


I think this should work but I would always try to avoid depending on other shared libraries if building an audio plug-in. SetDllDirectory will change the dll search directory for the whole host. This would have unforeseen consequences if any other part of the host - including any past or yet to be released plug-ins - will require a library with the same name. This can easily happen for example if your company releases several products and/or versions. I've therefore tried to avoid using dlls in my plug-ins and tried to use static linking as much as possible instead.

I do agree with you, but there is no obvious way to avoid dll's entirely in this case. I've reduced the number of them, and I also reset the original search path before exiting VSTPluginMain, which means that the custom dll path only takes effect during the construction of my plugin. I'll investigate whether this code could be moved into my AudioProcessor constructor instead - just to avoid customizing JuceVSTWrapper.

Hey Sigurd. Doesn't Windows search in the current dir before looking in the system path? I've ran many of my applications on systems that had duplicate version of DLLs needed by my software in their system path. But they always picked up the ones in the same dir as the exe. I also use _putenv() and _getenv() to set things up in my AudioProcessor so I don't need to hack the JUCE source.



Hi Rory! The problem is that the dll's I want to pick up is not (and should not be) in the same directory as the plugin dll itself. The rest is installed elsewhere and we use an environment variable set by the installer to locate where. 

I solved the Juce source hack by moving the necessary code inside the createPluginFilter() method and that seems to work well.