Link to a dll in specific location in VS2010 c++

Question

How can I get my own dll to use a dll in a specific location?

I have build an 32bit Excel dll (a .xll). I am using the Python C-Api in the dll. Problem is in general there is only a 64bit Python installation. The 64 python26.dll is located \\System32 . If I put the 32bit python26.dll in the Excel exe Folder or in \\SysWOW64 everything is fine, but usually I have no access to those folders. Placing the 32 bit python dll in the xll folders does not help, it seems \\System32 comes first.

I there any solution without linking explicitly using "LoadLibrary" and many times "GetProcAddress".? Any option in VS2010?

Many thanks for your help.

Answer 1

You are right, the search order has the system directories first (and for a reason ). This is a traditional situation with plugins. The applications themselves can store their dependent libraries in their own program folder and be fine, because that has the highest priority. Plugins commonly don't have that luxury.

The solution might be to use delayed loading for the DLL. If you have a program like this:

int main()
{
  Py_Initialize();
}

...and you link it with python26.lib , it will create a static entry in the import table, pointing to python26.dll!Py_Initialize . Because the import table is processed before your code runs, you can't say which python26.dll you want to use, where to find it etc.

But if you set linker flag /DELAYLOAD:python26.dll and add MSVC's delayimp.lib to the build, it will postpone loading the Python DLL until some function from it is called. So now you can make sure you load the correct one: the import table has just the base name of the dependency ( python26.dll ) and if some library with the same name is already loaded, it will just reuse it. So you can preload the one you want from any location of your choice, then let the delayed loader do its job, like so:

int main()
{
  LoadLibrary(TEXT("C:\\Program Files (x86)\\...\\...\\python26.dll"));
  Py_Initialize();
}

---

But even with that, you might face another problem. The fact that the first loaded module with the correct base name is used by default means that even if you managed to do everything else right, there could still be some other Excel plugin or some silly Shell extension loaded (eg when the user goes to the "Open file" dialog), which would load their own python26.dll with possibly incompatible API, built with another compiler or anything else, which could ruin your day.

So I would also recommend you bundle your own custom version renamed to something like productname-python26.dll and link to that instead. There surely would never be a similarly named DLL by any other product, so you would be safe. In order to create a .lib file from a renamed DLL, try eg this guide .