I have a C++ application that is built in Visual Studio (2008) and links to a Boost DLL. When debugging, it seems like I need to copy the Boost DLL into the debug folder so the exe I am running in the IDE can link to it. I could use a post-build step to copy the DLL, but I was wondering if there is a setting in Visual Studio that can give it an additional search path for DLLs while debugging?
Asked
Active
Viewed 3,536 times
7
-
http://stackoverflow.com/questions/1776060/how-to-make-visual-studio-copy-dll-to-output-directory – Justin Ethier Jan 26 '10 at 16:52
-
The referenced question relates to using a post-build step, which I wish to avoid. – Permaquid Jan 26 '10 at 17:17
-
1JaredPar provided the hint to control the environment, rather than looking for some Visual Studio-wide library search location. It turns out that there is a Visual Studio setting that provides exactly what I wanted, by (apparently) adding another path to the PATH environment variable: Configuration Properties > Debugging | Environment. This is per project, and you can use environment variables. The only missing piece is documentation that describes exactly how the debugging environment I want to add is merged into the existing one. – Permaquid Jan 27 '10 at 03:47
-
See also the answer http://stackoverflow.com/a/2916103/536172 – AntonK Nov 11 '13 at 10:57
3 Answers
4
There is a slight mis perception here. Visual Studio itself does not directly control the loading of DLL's into an application while you are debugging. The loading of DLL's is directly controlled by the operating system. The operating system searches a set of interesting directories for DLL's when a load is requested.
The main way in which VS influences the DLL's loaded is by virtue of copying them to the build output directory. This is typically the directory in which the application is run and hence is one of the paths the OS will search for necessary DLL's.
What directories the OS searches is controlled by a few items. The easiest of which to alter is the environment variable (LIBPATH I believe). In Debug mode you could alter this environment variable to point to your other directory and have the DLL load from there.
There is nothing you can directly set in Visual Studio though.
JaredPar
- 733,204
- 149
- 1,241
- 1,454
-
It looks like you can alter the environment at debug time by setting Environment to be PATH=$(PATH);
where – Permaquid Jan 26 '10 at 19:01can contain environment variables referenced using $() syntax. You also need Merge=Yes. I would be interested if there is any documentation that explains the details. -
I marked this as "the" answer because it was the most helpful answer. Unfortunately the bit that says "there is nothing you can set in Visual Studio" is not correct (in my opinion) - see my comment under the question. However, thanks for the tip. – Permaquid Feb 02 '10 at 18:47
1
You can extend the PATH within Visual Studio by setting the environment variable. There's a good explanation here: How do I set a path in visual studio?
1
There are not of lot of options on Windows for DLLs that are implicitly linked to the EXE. Short from storing the DLL in the same folder as the EXE, you can store it in a directory that's listed on the PATH environment variable. Only c:\windows\system32 is guaranteed to be listed, you can't reasonably use that folder. An installer that changes the system environment would work, still not reasonable.
The only real option is to store the DLL in the WinSxS side-by-side cache. You'll need to write a manifest so that Windows can find the DLL. And you'll need to write an installer to put the DLL in WinSxS. Given the quality of the documentation, you'll need to really, really want to do that.
If this is only a consideration for debugging then perhaps it really isn't such a big deal to change the PATH on your dev machine. Use Control Panel, System applet.
Hans Passant
- 922,412
- 146
- 1,693
- 2,536