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.
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.
You will still have to run your exe through the ide for this to work.
Do I have to edit the PATH?
No
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.
Related
Im setting up a svn repository and wondering where i should put the dll files.
What Ive currently done is put them in the /bin/debug folder and then link them in my project file in visual studio.
is this the way to do it?
I presume you are asking about third party dll files, because the output (exe/dll) files generated by the project are better left unmanaged by SVN, because they are regenerated on each and every build.
What I usualy do is create a Lib folder, that is on the top level of my source tree, and put all needed references there, usually in additional folder divided by tool or by functionality (logging, emailing, apis, etc, etc...)
You should not put anything from the bin/Debug or bin/Release in your source control. If you do that, you will lose them when you clean your solution or your projects.
What you have to do is create a folder, within the solution folder for example, and reference the dlls in your projects. Any third-party dll that is in the references of a project will be copied to the bin/Debug or bin/Release folder when the project is compiled.
We typically have a seperate folder called dlls or something where we keep all 3rd party dlls/assemblies
Dlls are only needed at runtime. For a quick fix, you may copy your dlls in the Debug folder where your .exe file is. This Debug folder is at the same level as the solution .sln file in Visual Studio. Which thing you will have to do each time you start a new project... Debug folder
A better solution would be to copy all third party dlls, plus all the corresponding .h and .lib files, in 2 folders, say C:\dev\include and C:\dev\lib, and then add these 2 folders to your path environment variable once for all. This way, you'll be able to access them from all your projects, without having to copy them over and over.
Now, if you want someone to be able to run your project on another computer, you'll need to copy all needed .h, .lib and .dll files in your project in a separate folders that you create, say include and lib again, in your project directory where your own program files are, as mentioned in the previous posts. Project folder
PS. Sorry, it would not let me upload the 2 screenshots, so click on links.
I typically put it in a Lib folder within my Visual Studio project solution folder. I would also create sub folders all the way to indicate whether the dll is for a 32 bit or 64 bit build and also which version of Visual Studio was used to build it. So something like this: Lib\WIN32\VC2015\ . Then in the Project Properties of the project, under the Debugging Configuration Property, I set Environment to
PATH=$(SolutionDir)Lib\WIN32\VC2015;%PATH%
By doing this, I can have separate dll folders for different project configurations if I want to and also the dll files are in a good place to check into source control as well.
I have a folder on my hard drive, C:\Program Files\Microsoft SDKs, and I was wondering if it is safe to move it to an external drive. Does Visual Studio or any other tool depend on this particular folder?
There are quite a number of entries in the registry (at least in my registry) that point to that location, so it seems something would work in a less than optimal fashion. At a minimum, it would make the uninstaller a bit confused. It is probably safe to simply rename the directory temporarily and try your builds to see if they still work. Ultimately, though, it seems it would be cleanest to run the installation again to actually remove it and then install to a new location.
Yes. Most Unmanaged code in VSStudio refer to certain include files present in the include folder.
Also some exes in bin folder are also referred to (especially VS2008).
VS2005 refers to an internal Platform SDK location.
VS2008 refers to C:\Program Files\Microsoft SDKs\Windows\v6.0A
However most projects refer to this location via a macro. So if you can find a way to update the macro with the new location, then you should be fine.
Doing this may break some of your applications. If you added a reference to a project by browsing to a DLL installed in this folder, that project will not compile after you move this folder. If you haven't added any references in this manner, you might be OK.
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?
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.
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.
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?
As an example, I'm trying to add a reference to WatiN in Visual Studio 2008. I download WatiN and I have a folder on my desktop containing 5 files:
WatiN.Core.dll
WatiN.Core.xml
Interop.SHDocVw.dll
Microsoft.mshtml.dll
WatiN.Core.UnitTests.dll
WatiN.Core.UnitTests.dll.config
I can add my reference to WatiN.Core.dll and start coding in Visual Studio. But I have some questions:
Can I now delete the folder on my desktop? Were the files copied to the project bin?
What happens when I check my project into source code and another developer checks it out? Does he/she have to have the same folder on their desktop.
My thought was to create a lib folder in the project and reference the files in the lib folder. This folder will get added to source control so that everything should work for the next developer. But I have some questions about this solution:
Do I need all 6 of those files?
I believe the .config files have something to do with intellisense, but the project will build and run without them right?
How do I know what files to include apart from the WatiN.Core.dll. The project builds and runs with only WatiN.Core.dll and Interop.SHDocVw.dll. How am I meant to know what the dependencies are?
Any insight is much appreciated.
Adding a reference does just that. It adds a reference, so if the reference is to your desktop folder other developers will not be able to see the files. Also, if you delete the files you will have dangling references in your project. In general, don't reference files on your desktop.
Making a lib folder in the same source control tree as the project as you have suggested is a much better solution. Visual Studio will store the references as relative paths enabling other developers to compile the project.
You will have to study the documentation for the WatiN library to know which files are required by your application. You should not delete the .config file as it is not related to intellisense.
I would create a developement tree with all source files, library files, tools, docs, resources so that any developer can get a working project straight from source control without having to search for references.
Having referenced DLLs in a lib folder means that projectA is able to use version 1.0 of the DLL and projectB is able to user version 2.0 of the DLL.
When the solution builds it will get the DLLs from where they are referenced. If it cant find them the project wont build.
Have a look at the following articles.
http://www.codeplex.com/treesurgeon
As for which dlls you need to reference, you can go the way of only referencing what you need.
WATiN needs the WATiN.Core.dll and the Interop.SHDocVw.dll in order to run. As others have suggested, it's best to have a lib folder in your source control tree for external libraries so everyone can use relative references.
TreeSurgeon, mentioned above, is a good tool or you can at least use their folder structure as a model.
The Watin.Core.xml file should give you intellisense if you put it in the bin with the dll.
I believe you can only delete the folder if you are referencing the file directly from the bin folder (cut and pasted it there). If you are referencing the file from the folder than I believe you need to keep it there.
You may run into problems deleting the other files if the dll your referencing, references the classes in the other dll's.
I usually format my project directory like J-P Boodhoo. a main dir containing solution file, then a lib folder for all third-party lib, a src dir, a tools lib for third-party that wont be deployed.... For more info look here
I set in my project the reference path for all the needed folder, but if a developper checkout the trunk, he have to set all the reference path. Is there a way to simplify this ?
And am I using Visual Studio 2008.
Thank you.
I'm not sure which Visual Studio language you use, but if it's C++, then then file paths are stored in the .vcproj project file which should also be under version control. (NOTE: the .sln solution file does NOT store path settings) If you are careful to use relative, rather than absolute paths, it should be easily sharable among multiple developers.
In Visual C++ 2008, project files are XML so you can edit them directly. If you want to get really fancy, you can use .vsprops property sheets for additional control.
I use a shared folder on the network for stuff like that. And give that folder full trust. on the PDC i just have a login script that maps approriately. Its might not be the best way, but its worked for me without any issues.
Another solution I have used in the past is a common folder on each machine where all dependancies go, and have it syncronize with some sort of tool. I use Backup Exec which comes with Desktop and Laptop option which has a syncing feature, but other things work as well.