Configuration and role of Visual studio environment variables, working directory, VC + + directories, commands, etc.

When you debug a Visual Studio 2008 program, there are often dynamic link libraries (that is, DLL files) that need to be loaded into the project in order to rely on third-party libraries for program debugging.

These dynamic-link libraries, which are often beta versions or versions in development, or have several versions, can be potentially conflicting if you add the directory to the PATH directly, and if you copy directly to the directory in Visual Studio, if the test project is too many, Each time a new version of the dynamic link library update, you need to update several times, copy, paste miserable.

In the development process, how to let Visual Studio link these lib and DLL files will be better?

In general, there are several ways to change the environment variable settings for Visual Studio:

1. Add directly to the system's PATH variable :

2. This method is the simplest and most straightforward, but the downside is that it affects the global PATH setting, especially if you have a large number of DLLs for testing.

3. In the Visual Studio global settings, add the directory where the DLL is located to the PATH:

4. Through the Visual Studio menu ==> Tools ==> Options ==> projects and Solutions ==> VC + + directories, select "Executable" in the dropdown box and add the path where the DLL is located.

5. Copy all DLLs directly to the Visual Studio project directory, or to the folder where the executable file is generated (by default, the Debug or Release directory):

6. This method is also very simple, but when you have several projects, each time you update the SDK and its DLL files, you will have to update all the projects, this is not in line with the uniqueness of the engineering guidelines.

7. When debugging a program, let Visual Studio help you switch the current working directory to the appropriate directory for the DLL:

8. In Visual Studio ==> Project ==> properties ==> Select configuration ==> Configuration Properties ==> Debugg ing ==> working directory where the DLL is located so that when you debug the program, Visual Studio switches the current working directory to this directory, which automatically reads the DLL files in this directory.

   The advantages of this method are obvious and simple! Side effects are also obvious, after you switch the current working directory, you may not be able to find the program's configuration file, in the program, such as "./config.ini" can not be found; In addition, you have to put all the DLLs in this working directory, otherwise you will be prompted to find that xxx.dll problem.

9. The last method, which I think is the best method, is to temporarily add a directory to the PATH environment variable in the Visual Studio project properties:

10. There is a similar introduction on MSDN: Howto:set environment Variables for Projects, the method is simple, in the "Project Properties" ==> "Debugging" ==> "Environment", add something like the following:

    path=%path%;$ (TargetDir) \dlls

    This allows the $ (TargetDir) \dlls to be temporarily added to the system PATH to which the project belongs.

We can choose the above method flexibly according to the actual situation of the project.

Configuration and role of Visual studio environment variables, working directory, VC + + directories, commands, etc.