Why can't Visual Studio find my DLL?

Question

In Visual Studio 2010, under VC++ Directories > Executable Directories, I have specified the path to glew32d.dll. However, when I run the executable, it still complains.

On the other hand, if I copy the DLL into the local folder and run the executable then, it doesn't complain.

Can someone please tell me how to fix this? Also, why is Visual Studio not recognizing that path?

Update Scenario: I currently use a template project which I use as a starter code for a lot of my projects. This template depends on glew32d.dll. I usually store all dependent dlls in a common bin folder. I was hoping to reference this folder and Visual studio could read the dlls from there, instead of me having to copy the dlls everytime. What would be a good way to handle this?

Solution 1

Specifying the path to the DLL file in your project's settings does not ensure that your application will find the DLL at run-time. You only told Visual Studio how to find the files it needs. That has nothing to do with how the program finds what it needs, once built.

Placing the DLL file into the same folder as the executable is by far the simplest solution. That's the default search path for dependencies, so you won't need to do anything special if you go that route.
To avoid having to do this manually each time, you can create a Post-Build Event for your project that will automatically copy the DLL into the appropriate directory after a build completes.

Alternatively, you could deploy the DLL to the Windows side-by-side cache, and add a manifest to your application that specifies the location.

Solution 2

I've experienced same problem with same lib, found a solution here on SO:

Search MSDN for "How to: Set Environment Variables for Projects". (It's Project>Properties>Configuration Properties>Debugging "Environment" and "Merge Environment" properties for those who are in a rush.)

The syntax is NAME=VALUE and macros can be used (for example, $(OutDir)).

For example, to prepend C:\Windows\Temp to the PATH:

PATH=C:\WINDOWS\Temp;%PATH%

Similarly, to append $(TargetDir)\DLLS to the PATH:

PATH=%PATH%;$(TargetDir)\DLLS

(answered by Multicollinearity here: How do I set a path in visual studio?

Solution 3

try "configuration properties -> debugging -> environment" and set the PATH variable in run-time

Solution 4

To add to Oleg's answer:

I was able to find the DLL at runtime by appending Visual Studio's $(ExecutablePath) to the PATH environment variable in Configuration Properties->Debugging. This macro is exactly what's defined in the Configuration Properties->VC++ Directories->Executable Directories field*, so if you have that setup to point to any DLLs you need, simply adding this to your PATH makes finding the DLLs at runtime easy!

* I actually don't know if the $(ExecutablePath) macro uses the project's Executable Directories setting or the global Property Pages' Executable Directories setting. Since I have all of my libraries that I often use configured through the Property Pages, these directories show up as defaults for any new projects I create.

View more solutions

Comments

[Cody Gray]

@muntoo: What? Also, I disagree with the way you edited the last line. There aren't two separate questions there, so the original grammar was correct. The OP is asking how they can fix this in light of the fact that VS is not recognizing the path. The only reason they care about VS not recognizing the path is because it might lead them to a solution.

[MSalters]

Another "dirty" trick is so set the working directory of your program to that of glew32d.dll.

[brainydexter]

I'm a little confused by 'That has nothing to do with how the program finds what it needs, once built.' If not that, then what is the use of 'Executable Directories' ? Also, I edited my question with my current scenario. Please suggest me what would be a good way to deal with it.

[Cody Gray]

@brainy: I'm not sure what part of my answer was unclear. The Visual Studio linker uses the specified path to find the DLLs it needs while building your program. That's not the same thing as what your program needs while running. Were you choosing to statically link to glew32d.dll, that would be a different story. But since you're dynamically linking, the linker step of the compile AND your program at execution both need to be able to locate the DLL. You've solved part one, but not part two. In light of your update, I think the best solution is a post-build step that copies the DLL.

[brainydexter]

Thanks. that answers my concern.

[Nav]

Come on...there has to be a way for VS to find the DLL's during runtime. In VS2010, I couldn't find any way to reference the DLL's. It just had an option to reference the other projects in the sln. How does VS find it's own DLL's from Program Files during runtime? There has to be a way. Using the post-build event worked, but it seems wrong to depend on it. There should be a way to specify the path to the dll's for runtime execution. Anybody knows how?

[BConic]

Exactly what I was looking for, thanks!

[Cody Gray]

@Nav My answer contains a link to the DLL search order. That is how Visual Studio finds its DLLs. You can specify the path, by modifying the search order, but I don't recommend it. It is disruptive and serves little purpose. I talk more about that here; although the answer focuses on managed .NET code, the information is the same.

[Ruud van Gaal]

In VS2013 at least, I actually have to add a binary search path, since by default it can't find DLL's even if they are located in the same directory as my 'Working Directory' (a Project Property). Here I right-click the project, select 'Properties' and set Configuration Properties->Debugging->Environment to PATH=.;%PATH% . The '.' is there to make the exe see the DLL's local in the Working Directory. Similarly you could add the directory where glew32.dll lives in that setting.

[Cody Gray]

@ruud DLLs are supposed to go in the same directory as the EXE. You can easily have MsBuild dump them into the same directory when it builds, or, failing that, copy them there as a post-build event. Relying on a working directory is quite fragile. What happens if the user creates a shortcut to your app and changes the working directory to something else? Boom, crash, can't find the DLLs. The EXE directory is at the top of the DLL search order. The working directory is at the bottom. Having it any higher is a massive security risk.

[Ruud van Gaal]

Yes, DLLs next to the EXE. But the working directory is not at the bottom inside Visual Studio, it seems. I have to add 'Environment=PATH=.;%PATH%' otherwise it doesn't work. So by default (if I leave that out), DLL's in the working directory are never found. Which seems odd to me.