vs. project Properties Summary of some configuration items (important)

The following content is "original" + "reprint"

First, the solution and project folders contain relationships (C + + projects):

The VS solution and the individual project folders, as well as the configuration files that correspond to the individual projects, assume that a new project SSYY, the solution is named Fangan, and the solution includes the project, when the outermost directory that is generated is Fangan content that represents the entire solution within this folder. In this Fangan folder, the package contains Fangan.sln solution configuration files and a Ssyy folder, and the Ssyy folder represents the entire contents of the SSYY project in this folder, which contains Ssyy.vcproj project configuration files and. h header files as well as the. cpp source files. If a new project named Ssyy2 is created under the Fangan solution, a ssyy2 folder will be generated under the Fangan folder to hold all the contents of the Ssyy2 project.

As can be summed up in the above narrative, the manager (solution or project) will correspond to a total folder, this Manager folder under the manager's configuration file and sub-manager. For example, the solution is a manager, and its folder contains the. sln configuration file and the Child manager Ssyy Project and child manager Ssyy2 project.

in addition, by default, the directory starting point for the project property setting is where the project configuration file is located, actually the project header file and the source file location.

add: Creating a default C # project in VS and building a default C + + project generates a different directory structure. In the case of a C # project, the solution Total folder contains only the solution profile SLN and a total project folder of two items, while the project Total folder contains C # source files, Project Profile proj, a Properties Property folder, An obj folder and a bin folder, where both the obj and Bin folders contain debug and release two folders. The obj folder holds the intermediate compilation result (which differs from the project type of the extension), while the Bin folder holds the resulting result (usually an EXE or DLL extension).

in the case of a C + + project, the solution's total folder contains only the solution profile SLN and a project Total folder and a debug folder and a release folder (four Where the debug and release folders hold the resulting EXE or DLL, note that if you do not use release build, there is no release folder, and the project Total folder contains C + + source file header file, Project profile and a debug folder and a release folder (it is important to note that the Debug and release folders here only hold the intermediate compilation result obj, not the EXE and DLL. If you do not compile with release, there is no corresponding release folder).

Thus, the C # project generates a more logical file directory structure by default, and the output EXE is in the total project folder, while the C + + project default EXE is located under the Total Solution folder. In addition to C # more reasonable, C # uses the bin directory, in the bin directory contains debug and release two directories, and C + + does not use the bin directory, directly using Debug and Releae two directories.

Secondly, the relationship between common project properties and system configuration variables:

If we set up a default VC project Ssyy, his default "General" column, "Output directory" is $ (solutiondir) $ (configurationname), As a result, debugging creates a debug (configurationname value of Debug) folder under the Solution folder and generates SSYY.LIK linker and Ssyy.exe files under this folder. The default "intermediate directory" is $ (configurationname), so a debug folder is created under the SSYY project folder (that is, where the project configuration file for Ssyy.vcproj is located) and the Ssyy.obj binaries are generated under that folder. The output file option under the General option under the default linker column is $ (OutDir) \$ (ProjectName). exe, where $ (OutDir) is already assigned in the "Output directory" option in the "General" section. " so the value of $ (OUTDIR) is defined in the Output directory property ."

In addition, the actual test results show that the output directory attribute can only be used to assign values to the $ (OutDir) system variable , and "Change the location where the generated. exe file is stored" has no relation. That is, if the $ (OutDir) value is set in the output directory in the C drive, and the output file is set to the location of the D-Drive, the final generated EXE file will be in the D drive, and the output file property determines the location of the output EXE file.

The value of $ (TargetDir) is automatically assigned to the EXE file location after the EXE file is generated. So it can be said that the "output file" ultimately determines the location of the EXE file, also ultimately determines the value of $ (TargetDir), $ (TargetPath) and $ (TargetDir) The behavior is similar, this does not repeat.

The above two paragraphs say so much, the summary is, by default, "Output directory" and "Output file" two properties corresponding to the directory is the same, so it is convenient (of course, the output file value in the output directory based on the value of the EXE file name also contains). If two are different, the intermediate generated linker is in the output directory, such as Xx.ilk and xx.pdb files, and the resulting Xx.exe file is in the directory where the output file property is set.

In addition, the above two paragraphs can be summed up, when debugging the program, the value of the system variable $ (OUTDIR) is determined first, while the value of $ (TargetDir) and $ (TargetPath) is determined after the EXE file generation. That is, the value of the system variable $ (OUTDIR) is determined by the output directory property of the VS project, while the value of $ (TargetDir) and $ (TargetPath) is determined by the output file property of the VS project. That is, setting the "Output Directory" property of VS is equivalent to setting the value of $ (OutDir), "Output directory" is a prompt on the interface to receive the user input configuration information, and then put this specific configuration information into the system contents of the variable $ (OutDir).

Other commonly used properties are the "working directory" item in the "Debug" column, which is empty by default, but indicates that the working directory is the project directory, which is the directory where the project configuration file ssyy.vcproj. The working directory represents the destination directory for an operation, which changes with the directory determined by objects such as OpenFileDialog, SaveFileDialog, and so on. The " working Directory" property is the only default directory that is recognized after the program is run, that is, you only know this directory after work, and the working directory name describes the image , (you can set the directory of LIB and DLL libraries you depend on as your working directory. However, it is common to put Lib in the Lib directory under the solution, put the DLL in the bin directory under the solution, such as generating a txt text file while the program is running, if the absolute path is not specified during the file creation, only the file name of the created file is specified. Then this text file will be built in the working directory by default, of course, read some of the configuration files are also found in the working directory, but to illustrate, the resulting EXE file is not related to the working directory, and will not be placed in the working directory. In general, the working directory is the directory that is read by default while the program is running. For DLLs, if the program before running into memory a bit like a static link, at this time the DLL can be placed in the EXE executable directory, if the DLL is running in the dynamic loading of the general in the working directory, such as plug-ins are placed in the working directory. That is, the working directory is the only recognized default directory during the run, the working directory in the code with functions such as getcurrentdirectory, the most specific code between the bottom of the 1. The working directory can be different from the execution directory, for example, a person living in Beijing, but his work location is not necessarily in Beijing, probably in Tianjin.

" add to the Working directory: vs working directory settings are for debugging, that is, after you start debugging, start a new process, automatically set the working directory of the new process to the working directory of the VS project properties, and then start the corresponding EXE program." However, if you do not use vs Debug startup EXE, but directly double-click the exe file to start a new process, the working directory of the new process will be automatically set to the directory where the EXE file, which is different from the VS startup debugging. So if you do not copy the contents of the working directory in the directory of the EXE, you will run an error, because the working directory is no longer set in VS, but the directory where the exe file resides. Finally, to say, the default VC + + project in the work Directory project value is empty, the default is the VS project is located in the directory that the. vcproj file is located in the directory, the C # project is not tested by default, the same estimate and VC. 】

The same level of option " command " option under Debug options and working directory options is set, where the EXE file is started when debugging is used, since the normally generated EXE is placed under the Debug or release directory in the Bin directory, so the command option is generally "bin\$ (Configuration) \$ (ProjectName). exe ", the default is also this value, of course, it can be changed, but at this point, it means that the EXE started in debug state is the EXE file set in the" command "option, Instead of the default bin directory under Debug or release EXE file. Finally, the above-mentioned "debug" refers to the start EXE under VS, including the debug mode and release mode, do not interpret debugging as only debug mode. 】

The Command property item in the Debug column , this property represents the full name of the EXE file that the debugger will start, including the pathname, which defaults to $ (TargetPath) , The TargetPath represents the full pathname of the target output file, so it typically represents a value equal to the value represented by the output file property. Of course, you can also manually change the value of the Command property, such as changing to C:\aa.exe, and the output file value is \ C Bb.exe, if the output file is in the same directory without Aa.exe (because the linker only generates Bb.exe and does not generate aa.exe at all), the debugger cannot start Aa.exe, prompting for no aa.exe. Of course, if the directory already has a Aa.exe file (you can force the assignment of a copy of the Bb.exe file and named Aa.exe), the debugger will be able to debug normally.

The additional dependencies item under the input option under the linker column. This is the static library that is used when you set up a program link. Equivalent to the "code" that the link has been compiled. As a result, we can simply assume that these libraries are equivalent to our own. cpp files, except that these libraries are compiled. CPP (only the library name is needed here, and the search path is set elsewhere).

The setting for additional dependencies is equivalent to writing the "#pragma comment (lib," library name. Lib ") statement in the code, if the relative path is used as follows:

#pragma comment (lib, "... \\debug\\TestLib.lib ") where the backslash is to be double-backslash, because it is a program that interprets the double quotation marks including the string that needs to be escaped, to distinguish the include, #include". \testvideoapplication.h "is not a string that is interpreted by the program, so it is not escaped.

Here is a multi-project example (VC + + example): (From: http://blog.163.com/zhang_bo1983/blog/static/16992223020123753334981/)

Solutions and Projects:
From VC6, the VC series uses solutions (solution) instead of the original workspace for organizing and managing multiple related projects (project).
The article first demonstrates a virtual solution and the directory structure that we expect to get, and then uses the VC2008 Project Setup feature to achieve our needs step-after-step.
Virtual Solutions:
The virtual solution, named GMA, contains a dynamic link library project Chocolatemilk and an application project Puremilk, which requires a third-party library Log4cxx (Apache log4j C + + ported version for log output). "Note in this example that the Chocolatemilk project only generates one dll,puremilk to generate only one EXE"
Log4cxx is compiled in the form of a dynamic library, so we need 3 things for it, namely header files, import libraries (Log4cxx.lib, log4cxxd.lib), and dynamic link libraries (log4cxx.dll).
Let's say we expect the directory structure to look like this:

1. GMA is the solution catalog
2. Puremilk and Chocolatemilk are project catalogs
3. The Lib directory is used to store import libraries or static libraries (including third-party libraries and their own projects)
4. include header files for third-party libraries (you can see that all the contents of a third-party library are distributed in Lib, include, and bin)
5. The bin directory holds all dynamic link libraries and execution files, including its own outputs and third-party libraries, distinguishing between release and debug two versions. In addition, the program requires external data files and configuration files needed at startup, etc. can be placed in the directory
6. Temp is used to hold temporary makefile, where compile holds the obj file generated at compiler compile time, and link stores the linker's output file.

7.PureMilk and Chocolitemilk two items header files and source file locations do not move, still in the respective project folder.
The above directory structure clear, one side, when our program needs to make the installation package or to package the source code
When it's released, it makes life easier for us to ^_^
We only need to package all the files in the "/gma/bin/release/" directory when we make the installation package.
When we publish and transfer the source code, we can package all the files and directories under "/gma/" except the temp directory (or bin if you do not need to execute the file).

Our demand is clear, but VC (VS2008) does not automatically do for us all the above things. However, we do not need to write a complex compilation script (makefile), simply modify the project's default settings.
What we need VC (VS) to do for US includes:
1. Use "/gma/temp/compile/" as the Intermediate Directory for Project compilation
2. Use "/gma/temp/link/" as the output directory for project links
3. When the project is an application, copy the execution file to "/gma/bin/release/" or "/gma/bin/debug/" at the end of the build, and when the project is a dynamic link library, in addition to copying the DLL to the Bin, copy the import library to "/gma/lib/"
4. When the project is an application, run the Execute file under "/gma/bin/debug/" or "/gma/bin/release/" while debugging, and use "/gma/bin/debug/" or "/gma/bin/release/" as the working directory
First look at the macros that you can use in your project settings, which are commonly used:

ConfigurationName	Configuration name, usually debug or release
IntDir	Intermediate directory used by the compiler, output obj file
OutDir	Output directory used by the linker
ProjectDir	Project directory
ProjectName	Project name
SolutionDir	Solution Catalog
TargetDir	directory where the destination output file resides
Targetext	The extension of the target output
TargetFileName	Target output file name, including extension
TargetName	Target output name, not including extension
TargetPath	Full path name of the destination output file

The following figure is an example of all the settings for a project:

Note: As can be seen from the figure above,TARGETDIR refers to the target directory, which is a directory. The TargetPath is the target path, including the specific file name .

Here's how to get started with the project setup for the example:

To set up Chocolatemilk first:
1. Use "/gma/temp/compile/" as the Intermediate Directory for Project compilation
2. Use "/gma/temp/link/" as the output directory for project links

Note that the highlighted section first changes the configuration to all configuration, which allows us to simultaneously modify the debug and release parts;
Output directory (export directories, linker) fields fill in:
$ (SolutionDir) \temp\link\$ (ProjectName) \$ (ConfigurationName)
Intermediate Directory(intermediate directory, compiler) field fill in:
$ (SolutionDir) \temp\compile\$ (ProjectName) \$ (ConfigurationName)
3. Copy the dynamic link library to "/gma/bin/release/" or "/gma/bin/debug/" at the end of the build and copy the import library to "/gma/lib/" because if not set, the generated DLL and LIB are in the output directory set above.
We usually add the letter "D" after the debug version of the output library to indicate that this is the debug version, and in the Debug configuration, modify the Import Library field:

VC allows us to set the script to execute before and after the build, so in order to complete 3,
We need to write the script that was executed after the build:

Fill in command line, under Debug configuration:
Copy $ (TargetPath) $ (solutiondir) \bin\$ (configurationname) \;
Copy $ (TargetDir) $ (TargetName) D.lib $ (solutiondir) \lib\;
Release configuration:
Copy $ (TargetPath) $ (solutiondir) \bin\$ (configurationname) \;
Copy $ (TargetDir) $ (TargetName). Lib $ (solutiondir) \lib\;
The reason is to set it separately because the VC does not represent the import library's macro name-_-p
OK, so far, you can compile the Chocolatemilk project and try to see if everything is OK, but make sure the target directory of the copy is set up beforehand.

Next we set up the application project Puremilk:
1. Use "/gma/temp/compile/" as the Intermediate Directory for Project compilation
2. Use "/gma/temp/link/" as the output directory for project links
Change the configuration to all configuration first, so that we can modify the debug and release parts at the same time;
Output directory (export directories, linker) fields fill in:
$ (SolutionDir) \temp\link\$ (ProjectName) \$ (ConfigurationName)
Intermediate directory (intermediate directory, compiler) field fill in:
$ (SolutionDir) \temp\compile\$ (ProjectName) \$ (ConfigurationName)
3. Copy execution files to "/gma/bin/release/" or "/gma/bin/debug/" after build ends
Fill in command line, under all configurations:
Copy $ (TargetPath) $ (solutiondir) \bin\$ (ConfigurationName);
4. Run the execution file under "/gma/bin/debug/" or "/gma/bin/release/" while debugging, and use "/gma/bin/debug/" or "/gma/bin/release/" as the working directory

Command field fill in: $ (solutiondir) \bin\$ (configurationname) \$ (TargetFileName)
Working directory fields fill in: $ (solutiondir) \bin\$ (configurationname) \
That's it, and now you can compile the executable and debug it.

With VS2010 as the column, some of the project properties screenshots are as follows:

First, commissioning-"command

As set above, if the project name is SS, then the value of the TargetName system variable is ss,targetext is the extension exe, at which point the Debug button (the Small triangle button in VS) will start the Ss-xx-.exe file in the directory shown in the figure.

Note: All options under the Debug section are for debugging services, and if you do not use the Debug button, these options will not work. As for the VC + + directory and the C + + column is for the compiler to work, can not tell the compiler where to find the header files, library files and other things, or set some other compiler options, this does not repeat.

II. linker-"general-" output file (indicates where the linker-generated EXE file is placed and the generated EXE file name)

Above, if the project name is SS, the connector generates an EXE as the Ss-yy-.exe file in the directory shown in the figure. In general, the location and name of this file is the same as the command option described above to indicate that the linker generates the same files as the files used during debugging. (Note that if you do not modify the source code when you debug, and then click the Debug button, to speed up debugging, the program will not be re-linked, that is, the linker will not start)

After I have done some experiments have proved that if the EXE has been generated through the linker, manually modify the exe file name, debugging as long as the image shown in the file name of the option is also modified, the same can be debugged and start the EXE program.

Third, linker-"input-" Additional dependencies (this option is the static library used when setting up program links.) Equivalent to the "code" that the link has been compiled. As a result, we can simply assume that these libraries are equivalent to the. cpp files that we wrote, except that the libraries are compiled. CPP only)

Finally, in the development process, how to let Visual Studio link these lib and DLL files will be better.

Because when you debug a Visual Studio 2008 program, there are often some 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 general, there are several ways to change the environment variable settings for Visual Studio: Add directly to the system's PATH variable:

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. In the Visual Studio global settings, add the directory where the DLL is located to the PATH:

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. 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):

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. When debugging a program, let Visual Studio help you switch the current working directory to the appropriate directory for the DLL:

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. 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:

There is a similar introduction on MSDN: How To: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.

Attached 1:c# get set working directory and execute directory code

(1) Get and set current working directory

A) System.IO.Directory.GetCurrentDirectory ()

Description: Gets the fully qualified path to the current working directory of the application. This method is an encapsulation of the getcurrentdirectory function of the Win32 API.

For example: ' "C:\Documents and Settings\Administrator\My Documents"

b) System.Environment.CurrentDirectory

Description: Gets or sets the fully qualified path of the current working directory. The System.IO.Directory.GetCurrentDirectory () method is called inside the property, and the effect is equivalent.

For example: ' "C:\Documents and Settings\Administrator\My Documents"

c) System.IO.Path.GetFullPath (".")

Description: Gets the absolute path of the specified path string. You can also use GetFullPath (". \"), GetFullPath (". \")

For example: ' "C:\Documents and Settings\Administrator\My Documents"

(2) Get and set the current execution directory

A) System.Windows.Forms.Application.StartupPath

Description: Gets the path to the executable file that launched the application, not including the name of the executable file. Commonly used in WinForm.

For example: ' "D:\Projects\MyTest\bin"

b) System.AppDomain.CurrentDomain.BaseDirectory

Description: Gets the base directory that is used by the Assembly resolver to probe assemblies. Returns the end of the path with "\"

For example: ' "D:\Projects\MyTest\bin\"

c) System.AppDomain.CurrentDomain.SetupInformation.ApplicationBase

Description: Gets or sets the name of the directory that contains the application. Returns the end of the path with "\"

For example: