DLL?

Started by
4 comments, last by AAA 14 years, 1 month ago
Before I begin, I'm using Visual Studios. I have a project where I create a dll that calls other library dlls that I didn't make to run. My dll is used by my program, .exe, and everything works fine if I put the library dlls within the same folder as my created dll and executable. When I try to put the library dll's in a subfolder and run the executable from Visual Studios it says it can't find the library dlls. I've tried everything to try to get the subfolder library dlls to be found but I can't. Could someone experienced with Visual Studio give me any suggestions? Thanks.
Alabama Man!!!
Advertisement
If you really want to do this, you can, but it'd just be easier to put the DLLs in the same folder as your EXE. Is there any reason that you don't want to do this? That being said, you can probably get it to work by using delay load on the DLLs by using the /DELAYLOAD linker option and calling SetDllDirectory() with the path name of the folder before any of the DLL functions are called.
Your problem has little to do with the development environment you are using, but with the way your operating system is looking for dynamic libraries. You will find a summary of how dynamic link libraries are searched for here:

Dynamic-Link Library Search Order

That being said, you can always load the library yourself specifying a path relative to your application directory, using a call to LoadLibrary.
I agree with SiCrane. From experience and in the interest of sticking with common usage, put all of your "always loaded" DLLs in the same directory as your program, NOT a sub directory. And while yes, this can be done. It opens up enormous headaches for debugging problems that just don't exist if they are in the same directory (because on windows it searches the local directory FIRST!

Now you can but ALL your program binaries in a sub directory of the real app ... but that INCLUDES your exe.

The other time you use sub-directories is when implementing a plug-in system ... a system where the program loads first, then looks for other add-ons to load while it is running, add-ons that may be installed and uninstalled separately from the program itself (think Photoshop plug-ins or firefox add-ons).
Alright Xai and SiCrane, you guys seem to know what you're talking about and experienced. I'll just keep them in the same folder. For some reason I thought it would seem more organized, but it doesn't seem like it's worth the trade off. Thanks.
Alabama Man!!!
You can get around this by always specifying the full path to your DLL. In my opinion it's the preferable method as it removes the silliness of having to know the current directory or in case some other part of the code messes with your current directory.

Something like this:

TCHAR szBuffer[MAX_PATH];::GetModuleFileName( 0, szBuffer, MAX_PATH );    // Get path of the executable::PathRemoveFileSpec( szBuffer );                // Remove the exe name::PathAppend( szBuffer, _T( "MySubDirectory" ) ); ::PathAppend( szBuffer, _T( "MyDllName.dll" ) );HMODULE hDll = ::LoadLibrary( szBuffer );

This topic is closed to new replies.

Advertisement