Sign in to follow this  
DigiMan Shart

DLL?

Recommended Posts

DigiMan Shart    201
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.

Share this post


Link to post
Share on other sites
SiCrane    11839
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.

Share this post


Link to post
Share on other sites
Hyrcan    144
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.

Share this post


Link to post
Share on other sites
Xai    1838
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).

Share this post


Link to post
Share on other sites
DigiMan Shart    201
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.

Share this post


Link to post
Share on other sites
AAA    196
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 );

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this