Are there any guides on how to point my application to look for Turboactivate.dll in that location? This does not happen automatically for VST3 audio plugins.
All the other manufacturer's plugins are in the same folder, so it goes back to the issue of clashing with other software unless I can rename the .dll.
Good practices for Turboactivate.dll locationAnswered
My LimeLM implementation is in audio plugins, which run in host software. Placing Turboactivate.dll in the same directory as my application (VST3 plugin) will not work, because the default search location will be the .exe of the host application.
We are currently using a static library to work around that but it looks like this is not recommended.
In this case, what are good practices for storing Turboactivate.dll on the user's system and what is a good way to load it from a custom path?
The system32 folder does not seem ideal, since it can clash with applications from other applications using LimeLM - for example, an installer from another manufacturer installs an older version of the .dll which now creates issues for our application.
Answer
The best solution is to place the TurboActivate.dll alongside your plugin DLL and load dynamically at runtime.
Answer
There are a thousand ways to skin this cat. One way: create a subfolder for your app resources (like TurboActivate.dll) and install the TA dll there. Then use an AddDllDirectory() call early in your plugins life.
Tons of different ways to do this. Google “loading dlls” and add any qualifiers for whatever you're trying to accomplish.