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?
Related
I'm working on a project with Qt using the Visual Studio Addin in VS2010 Professional. Two branches of the project use two different Qt versions (4.8.4 and 5.0.2) so I have both versions of the addin installed (1.1.11 and 1.2.1). I'm also actively developing using at least two computers, both Windows 7, for which I have a networked, roaming user profile. I don't know the specifics of how this user account or network is setup.
Qt is installed in different locations on each system. If I set the correct paths in the Addin on one system (System A), it changes them for the other system (System B) and then complains to me that Qt doesn't exist at that directory when I later log into System B. Is there a way to save the paths to Qt versions on the system, without it affecting the paths on the other system? Or will I have to just deal with changing them each time I change computers?
EDIT:
I from looking through the source for the visual studio add-in, I found that these settings are saved as user registry values. I don't know much about Windows roaming profiles but I'm now assuming that user registry values are copied between computers just as their files are. I don't know if there's any way to move these registry values somewhere else without having to edit and recompile the add-in. I suppose the only other thing I could do is write a startup script to edit these settings upon login.
EDIT: Make sure visual studio on each computer can find the right add-in and the right environment variables on the computer you are using.
http://qt-project.org/wiki/QtVSAddin
In this documentation it talks about where it gets installed to:
"%USERPROFILE%\Documents\Visual Studio 2008\Addins"
So you could manually change the location of the addin, to some local system path.
How to -> Visual Studio Add In Manager
Or you could change the qt path that the Add-in refers to every time you log in, or right before opening visual studio.
Setting a system environment variable from a Windows batch file?
I would use version control to just get the files that you need for the project, and exclude/ignore all the environment specific elements of the project.
One way you could achieve this is:
To install Bazaar. Create a standalone tree of the code on a shared drive or on a location on the harddrive that both users have access to.
Do an initial add of all your source and header files and your qt .pro file.
Checkout or branch the code to user specific folders. In those user specific folders, let Visual Studio create all the user specific, Qt Add-on specific, (etc) files.
Also create a .bzrignore file with files and folders like these listed:
Debug
Release
x64
*.ncb
*.suo
*.user
*.vssscc
*.scc
*.vspscc
*.lnk
*.bak
*.aps
*.pro.user
object_script.*
Makefile
Makefile.Release
Makefile.Debug
Then when you want to try your build for each setup, finish your edits, commit/push your changes on the user that did the edits, and update/pull on the user that wants the changes.
Although the version control may be a little tricky to get started with, it will make project collaboration both scalable, trackable, and very manageable!
And you aren't limited to Bazaar. Check this wiki out if you need ideas.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Another way that you could try to go about doing this, is to have all the source code in some path (either absolute or relatively up from your projects locations), or on the computer, and have the project folders reference those paths in the project folders, but have two separate project folders. This would not be nearly as elegant, but would work.
C:/path/to/vs_proj1
C:/path/to/vs_proj2
C:/path/other/proj/source
And in the properties for vs_proj1, and vs_proj2, in the part about locating source files, have ../other/proj/source to find it relatively, or put the absolute path C:/path/other/proj/source.
Also two other things to be aware of when sharing projects over a drive like this, is that when you are referencing libraries, you may want to store that information in a user specific macro file in Visual Studio and reference the macro in your project settings.
Visual Studio - Where to define custom path macros?
And while I'm here, you may need to #define some things in your program to allow for behavior for one version of Qt that isn't in the other.
So for example, in the source of your program, you might have:
#if QT_VERSION < 0x050000
// some Qt 4.x specific stuff, not in Qt 5
#else
// some Qt 5 specific stuff, not in Qt 4.x
#endif
Hope that helps.
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.
I am currently using Visual C++ to develop my DLL program. This DLL also uses outside executables inside my local hard drive.
When doing testing, I manually install the DLL using this command regsvr32 filename.dll at the Windows command prompt.
What I would like to do now is an installer, like the Installshield etc. So, after this I can easily install it on other Windows machines without the need to manually use the command prompt, copying those separates executables into the hard drive and so on.
Is there a way to do this the open source way? or Is it available inside Visual Studio? Need advice on best practice.
Another possibility since you're already using VS, you can create a "Setup and deployment project", found under "Other Project Types". This allows you amongst other things to select the output of another VS project (in the same solution), add registry entries, package files from the file system, and register (regsvr32) files. To register a DLL (once you have added it to the project), change the "Register" entry on the "Properties" Window to vsdrfCOMSelfReg. However if you're packaging other executables off the hard drive, I'm not sure how you would make sure that they run. You prob have to make sure that you package all their run-times and dependencies.
AFAIR this functionality is not available in the express editions of VS.
WiX is open source, and there's a free (no cost) version of InstallShield available for Visual Studio 2010, so both.
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 inherited a visual studio 2003 project which uses some custom build steps. I'm having some trouble with the path to the tool. Where does visual studio get its PATH? I've echoed out %PATH% in the custom build step and it has no resemblance to the system path. I did find a value in the registry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories
Path Dirs which looked like it might be the path used by visual C but chaning it doesn't seem to alter the path in VC. Any ideas?
Visual Studio has the annoying habit of 'playing' with your path, which leads to the effect you've seen.
The easiest way to work around it if you're willing to change the environment inside VS (which will change it for all your projects) would be to go to Tools > Options > Projects > VC++ Directories and add the required directories to the appropriate setting - in your case that should be 'Executable files'.
Another method I am using if I don't want to change the overall environment is to create a batch file that first calls vsvars32.bat for the appropriate compiler version, then manipulate the PATH variable and finally starts 'devenv'. I actually prefer this approach but it means your disk is littered with small batch files that you'll only use to kick off Visual Studio...