How do I Set an Executable's Search Path? - 【StackMirror】|visual-studio-2010|build

I'm not using the default Visual Studio project path to build my program into, because I want to emulate a release, and write tools to search for resources. After tinkering with the settings, I've got VS to output to the right folder, and to copy the DLLs to a bin folder in the main folder. However, I can't get the .EXE it generates to find the DLLs, it will only find what's in it's directory, but I don't want to be messy like that. The debugger works fine, but it won't work standalone. How do I tell VS to tell the .EXE where to find it's DLLs? Do I have to edit the PATH? That seems messy, as I've never had good experiences with it. I've tried Project Settings -> VC++ Directories, but it still won't find it, as I'm assuming that that's for .LIB files.

Here is a diagram of my folder hierarchy.

-root
--bin
---[Required DLLs]
--data
---[Program Resources (images, sounds, configs, etc.)]
--Program.exe

Using Visual C++ 2010 Express Edition.

2012-04-03 20:53
by smoth190

How do I tell VS to tell the .EXE where to find it's DLLs?

Edit the Release Run Configuration and change the working directory where your dlls reside.

enter image description here

You will still have to run your exe through the ide for this to work.

Do I have to edit the PATH?

2012-04-03 21:01
by Jason Huntley

I changed the working directory before, but it breaks my resource finder, which uses the working directory to find it's resources. I'm going to add diagram of my folder, because I can see this might get hard to visualize - smoth190 2012-04-03 21:21

Why don't you just consolidate all your binaries to a single output folder with your resources? Build a distribution. Update the build configuration to use the new output folder - Jason Huntley 2012-04-03 21:23

So, I should have my binaries and my resources under the same main folder? I usually just look at how commercial programs do things, and use that technique (The one picture in my diagram) - smoth190 2012-04-03 21:26

Typically, in a windows environment, you will find the dlls located in the same directory with the exe, that is if you're not using LoadLibrary, system libraries, or other libraries in PATH. You can still keep your resources in a separate sub-folder, so you can always reference them path relative and have the data separated from binaries - Jason Huntley 2012-04-03 21:35

Interestingly enough, I just took a look at how the Steam installation is setup. I noticed there is a Steam.exe and a Steam.dll, in the root folder. In the bin is various other DLLs, and another .exe. Is it possible that Steam.exe calls this other .exe, and that .exe references the DLLs? I would have no reason to do this, but if this is true, it would give me a reason to not have to organize my folders this way - smoth190 2012-04-03 21:37

It's quite possible the root is calling the bin binary. It also could be a 32bit exe detecting for 64bit and calling the new binary in bin. However, I'm not familiar with Steams layout, it could just be a utility exe with dll dependencies or they use LoadLibrary with the dlls in bin - Jason Huntley 2012-04-03 21:44

Ok, well, currently I only have one DLL, although more are expected. I guess it's so much trouble and error prone to organize this mainly based on the fact that I usually pick pretty over efficient (I know this is a bad habit...). For now, I will stick with the DLL-In-Application-Folder method. Thank you for explaining this to me in detail though, so I won't make future mistakes - smoth190 2012-04-03 21:48

This doesn't have anything to do with Visual Studio. It is Windows that can't find the DLL. It has no reason to look in an arbitrary subdirectory for a DLL. It isn't otherwise clear whether these are implicitly loaded DLLs or if you use LoadLibrary to load them yourself.

You don't have much of a problem if you use LoadLibrary(), just pass the full path name of the DLL. GetModuleFileName(NULL, ...) helps you build the path string. You'll have a Big Problem if these are implicitly loaded. In that case, there should be preciously few reasons to not store the DLLs in the same directory as the EXE. And yes, you don't want to mess with the PATH environment variable. Or the current working directory.

2012-04-03 21:04
by Hans Passant

Well, I understood that VS wasn't looking for the DLLs, I was just hoping there was an option that I could use to have it tell windows what to use. I don't use LoadLibrary(), though... would it be worth switching? I've never seen this method used before - smoth190 2012-04-03 21:21

No, using LoadLibrary is a very, very painful way to use a DLL. Storing implicitly loaded DLLs in a subdirectory requires 10000 points, a really good reason to give Windows a hard time to find those DLLs. This only makes sense if you, for some reason, want Windows to find another set of DLLs. Something that usually goes by the name of "DLL Hell". You create DLL Hell with the PATH environment variable. The solution you dismissed because you probably used it before and got a taste of what Hell looks like? Don't do it - Hans Passant 2012-04-03 21:29

I've had bad experiences with the PATH variable when I used to work with Java, which never installed correctly for me, so I always had to do it manually. I'm guessing the reason I've never seen any C++ tutorials use LoadLibrary() is because it creates the issue you described. I just recently dove into the world of DLLs and libraries and such, because I enjoy the idea of reusable code. It seemed so much simpler from the outside - smoth190 2012-04-03 21:34