First, the solution and project folders contain relationship (c++ project):
The VS solution and each project folder and the configuration file corresponding to the solution and each project include:
Suppose a new project ssyy is created, and the solution is named fangan. Note that the solution includes the project. At this time, the outermost directory generated is fangan, which means that the content of the entire solution is in this folder. This fangan folder contains the solution configuration file of fangan.sln and a ssyy folder. The ssyy folder represents all the content of the entire ssyy project in this folder. This folder contains the project configuration of ssyy.vcproj files and .h header files and .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 store all the contents of the ssyy2 project.
It can be concluded from the above description that the manager (solution or project) will correspond to a general folder, and the configuration files and sub-managers of the manager are stored in this manager folder. For example, the solution is a manager with a folder containing .sln configuration files and sub-manager ssyy projects and sub-manager ssyy2 projects.
In addition, by default, the starting point of the directory set by the project properties is the location of the project configuration file, which is actually the location of the project header files and source files.
Supplement: The directory structure generated by the default C# project and the default C++ project in vs is different. If it is a C++ project, the solution general folder only contains the solution configuration file sln and a project general folder and a Debug folder and a Release folder (a total of four things, of which the Debug and Release folders are in the Store the final generated exe or dll, note that if you do not use Release to generate, there will be no Release folder), and the general project folder contains C++ source file header files, project configuration files and a Debug folder and a Release file folder (it must be noted that the Debug and Release folders here only store the intermediate compilation result obj, not things such as exe and dll. If you do not use Release compilation, there is no corresponding Release folder).
Second, the relationship between common project properties and system configuration variables :
If we build a default vc project ssyy,
In his default "General" section:
The "output directory" is $(SolutionDir)$(ConfigurationName), so a debug (ConfigurationName value is debug) folder will be created under the solution folder during debugging, and the ssyy.lik linker and ssyy.exe file.
The "intermediate directory" is $(ConfigurationName), so a debug folder will be created under the ssyy project folder (that is, where the project configuration file of ssyy.vcproj is located), and the ssyy.obj binary file will be generated under this folder.
Under the "General" option under the "Linker" section:
The "Output File" option is $(OutDir)\$(ProjectName).exe, where $(OutDir) is already assigned in the "Output Directory" option of the "General" column. [ So the value of $(OutDir) is defined in the "Output Directory" property ].
另外，经过实际测试，发现“输出目录”属性只能起到对$(OutDir)系统变量赋值的作用，和“改变生成的.exe文件存放位置”没任何关系。也就是说，如果“输出目录”中设置的$(OutDir)值在C盘，而“输出文件”中设置输出文件的位置为D盘，最终生成的exe文件会在D盘，“输出文件”属性才决定输出exe文件的位置。
而$(TargetDir)的值是在生成exe文件后自动赋予值为exe文件所在位置。所以可以说，“输出文件”最终决定exe文件所在的位置，也最终决定了$(TargetDir)的值，$(TargetPath)和$(TargetDir)的行为是类似的，此不赘述。
上面两段说了这么多，总结就是，默认情况下“输出目录”和“输出文件”两个属性对应的目录是一样的，这样用着方便（当然，输出文件的值在输出目录的值的基础上还包含有exe文件名）。如果两个不一样，则中间生成的链接器用的如xx.ilk和xx.pdb文件等在输出目录，而最终生成的xx.exe文件在“输出文件”属性设置的目录中。
另外，上面两段话可以总结出，当调试程序时，系统变量$(OutDir)的值是最先确定的，而$(TargetDir)和$(TargetPath)的值是在exe文件生成后才确定的。也就是说系统变量$(OutDir)的值由VS项目的“输出目录”属性决定，而$(TargetDir)和$(TargetPath)的值由VS项目的“输出文件”属性决定。即设置了VS的“输出目录”属性就相当于设置了$(OutDir)的值，“输出目录”是界面上的提示用于接收用户输入的配置信息，然后把这个具体的配置信息存入系统内容的变量$(OutDir)中。
其它常用的属性还有，“调试”栏目中的“工作目录”项，这个属性默认情况下是空的，但表示工作目录是工程目录，也就是工程配置文件ssyy.vcproj所在目录。工作目录表示进行某项操作的目的目录，会随着OpenFileDialog、SaveFileDialog等对象所确定的目录而改变。“工作目录”属性作用是程序运行后唯一识别的默认目录，即工作后只认识这个目录，工作目录这个名字描述的就很形象，（可以将所依赖的lib和dll库文件所在目录设为工作目录，但一般是把lib放在解决方案下的Lib目录中，把dll放在解决方案下的Bin目录中），例如程序运行过程中生成一个txt文本文件，如果在创建文件过程中未指定绝对路径，只指定创建文件的文件名，那么这个文本文件默认就会建立在工作目录中，当然读取一些配置文件也在工作目录中查找，但要说明一下，生成的exe文件跟工作目录没任何关系，也不会放在工作目录中。总的来说，工作目录就是程序运行过程中默认读取的目录。对于dll，如果是程序运行前就进入内存有点像静态链接那样，此时dll就可以放入exe所在的执行目录，如果dll是运行中动态加载的一般放在工作目录，比如插件就放在工作目录。即工作目录就是运行期间唯一能识别的默认目录，工作目录在代码中用GetCurrentDirectory之类的函数获取，具体代码间最下面的附1。工作目录与执行目录可以不同，例如一个人住在北京，但他的工作地点不一定在北京，可能在天津。
【对工作目录的补充：vs中工作目录的设置是给调试用的，也即你启动调试后，启动一个新进程，自动把这个新进程的工作目录设置为vs项目属性中的工作目录，然后新进程启动对应的exe程序。但是如果不使用vs的调试启动exe，而是直接双击exe文件启动一个新进程时，会自动把这个新进程的工作目录设置为exe文件所在的目录，这是和vs启动调试不同的地方。所以如果发布的时候不把工作目录内的东西拷到exe所在的目录内，就会运行出错，因为此时工作目录不再是vs中设置的了，而是exe文件所在的目录。最后，说一下，vs中默认的vc++工程的工作目录项目的值是空的，代表默认是vs工程所在目录即.vcproj文件所在目录，c#工程默认没测试，估计和vc的一样。】
【同样在调试选项下的和工作目录选项同一级的选项“命令”选项是设置，使用调试时，从哪里启动exe文件，因为一般生成的exe放在bin目录下的debug或release目录下，所以命令选项一般为“Bin\$(Configuration)\$(ProjectName).exe”，默认也是这个值，当然可以更改，但此时意味着调试状态下启动的exe为“命令”选项中设置的exe文件，而不是默认的bin目录下的debug或release下的exe文件了。最后说一下，上面所说的“调试”是指vs下启动exe，包括debug模式和release模式，不要把调试就理解为只有debug模式。】
“调试”栏目中的“命令（Command）”属性项，【这个属性表示调试器要启动的exe文件的全名】，包括路径名，默认为$(TargetPath)，而TargetPath就表示目标输出文件的全路径名，所以一般情况下它代表的值就等于“输出文件”属性代表的值。当然你也可以人为的更改“命令”属性的值，比如更改为c:\aa.exe，而“输出文件”的值为c:\bb.exe，此时如果输出文件所在目录没有aa.exe的话（因链接器只生成bb.exe而根本不会生成aa.exe），调试器就不能启动aa.exe，提示找不到aa.exe。当然如果目录中已经有aa.exe文件（可以强制赋值一个bb.exe文件的副本并命名为aa.exe），此时调试器就可以正常调试通过。
“链接器”栏目下的“输入”选项下的“附加依赖项”项。此项是设置程序链接时使用的静态库。相当于链接已经编译好了的“代码”。由此我们可以简单的认为这些库就相当于我们自己写的.cpp文件，只不过这些库是编译好了的.cpp而已（这里只需要库名称即可，搜索路径在其他地方设置）。
“附加依赖性的设置”等同于在代码中写“#pragma comment(lib, "库名称.lib") ”语句，如果使用相对路径则如下：
#pragma comment(lib,"..\\debug\\TestLib.lib");其中的反斜杠要用双反斜杠，因为它是程序解释的双引号包括的字符串，需要转义一下，要区别include，#include "..\TestVideoApplication.h"中并不是由程序解释的字符串，所以不用转义。
下面举一个多项目例子(vc++例子)：（转自：http://blog.163.com/zhang_bo1983/blog/static/16992223020123753334981/）
解决方案与项目：
从VC6之后VC系列就使用解决方案（Solution）来替代原来的工作空间，用于组织和管理多个相关的项目（Project）。
文章首先演示一个虚拟的解决方案和我们期望得到的目录结构，然后使用VC2008的项目设置功能来一步一步达到我们的需求。
虚拟解决方案：
该虚拟解决方案名为GMA，包含一个动态链接库项目ChocolateMilk和一个应用程序项目PureMilk，需要使用一个第三方库log4cxx（Apache log4j的C++移植版本，用于日志输出）。【注意这个例子中ChocolateMilk项目只生成一个dll，PureMilk只生成一个exe】
log4cxx是以动态库的方式编译的，所以我们需要它的3样东西，分别是头文件，导入库（log4cxx.lib, log4cxxd.lib）和动态链接库（log4cxx.dll）。
假设我们期望的目录结构如下图：
1． GMA是解决方案目录
2． PureMilk和ChocolateMilk是项目目录
3． Lib目录用于存放导入库或者静态库（包括第三方库和自己的项目）
4． Include用于存放第三方库的头文件（可以看出第三方库所有内容分布在Lib、Include和Bin中）
5． Bin目录存放所有动态链接库和执行档，包括自己的产出和第三方库，区分Release和Debug两个版本。另外，程序运行过程中需要外部的数据文件和启动时需要的配置文件等等都可放于该目录
6． Temp用于存放临时生成文件，其中Compile存放编译器编译时生成的obj文件，Link存放链接器的输出文件。
7.PureMilk和ChocoliteMilk两个项目的头文件和源文件位置不要动，任然在各自的项目文件夹内。
上面目录结构清晰，一面了然，当我们的程序需要制作安装包或者要打包源码
发布的时候，它能够使得我们生活变得更容易^_^
制作安装包时我们只需将“/GMA/Bin/Release/”目录下的所有文件打包。
发布和转移源码的时候我们可以打包除了Temp目录以外“/GMA/”下面的所有文件和目录（如果不需要执行档，也可不包括Bin）。
我们的需求是明确的，可是VC 2008（VS2008）并不会自动为我们做好上面所有的事情。不过我们并不需要编写复杂的编译脚本（makefile），只需要简单的修改项目的缺省设置即可。
我们需要VC（VS）为我们做的事情包括：
1．使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录
2．使用“/GMA/Temp/Link/”作为项目链接的输出目录
3．当项目是应用程序时，在构建结束后拷贝执行文件到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”，当项目是动态链接库时，除了拷贝dll到Bin，还拷贝导入库到“/GMA/Lib/”
4．当项目是应用程序时，调试时运行“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”下面的执行文件，并以“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”为工作目录
首先看一下项目设置中可以使用的宏，常用的有：
ConfigurationName |
配置名字，通常是Debug或者Release |
IntDir |
编译器使用的中间目录，产出obj文件 |
OutDir |
链接器使用的输出目录 |
ProjectDir |
项目目录 |
ProjectName |
项目名字 |
SolutionDir |
解决方案目录 |
TargetDir |
目标输出文件所在的目录 |
TargetExt |
目标输出的扩展名 |
TargetFileName |
目标输出文件名，包括扩展名 |
TargetName |
目标输出名，不包括扩展名 |
TargetPath |
目标输出文件的全路径名 |
下图是某一个工程所有设置的例子：
注意：从上图可以看出，TargetDir指目标目录，是一个目录。而TargetPath是目标路径，包括具体的文件名。
下面开始进行所举例子的工程设置：
首先来设置ChocolateMilk：
1．使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录
2．使用“/GMA/Temp/Link/”作为项目链接的输出目录
注意高亮的部分，首先将配置改成All Configuration（全部配置），这样可以让我们同时修改Debug和Release的部分；
Output Directory（输出目录，链接器）栏位填入：
$(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName)
Intermediate Directory（中间目录，编译器）栏位填入：
$(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName)
3．构建结束后拷贝动态链接库到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”，拷贝导入库到“/GMA/Lib/”【这是因为若不设置，此时生成的dll和lib都在上面设置的输出目录中】
我们通常都会在Debug版本的输出库后面加上字母“d”以表示这是Debug版本，在Debug配置下，修改Import Library栏位：
VC可以让我们设置构建前后执行的脚本程序，所以为了完成3，
我们需要写构建后执行的脚本：
在Command Line中填入，Debug配置下：
copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\;
copy $(TargetDir)$(TargetName)d.lib $(SolutionDir)\Lib\;
Release配置下：
copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\;
copy $(TargetDir)$(TargetName).lib $(SolutionDir)\Lib\;
之所以要分别设置是因为VC没有表示导入库的宏名字 -_-P
OK，到此为止，你就可以编译ChocolateMilk项目试试是不是一切正常了，不过请确认拷贝的目标目录事先建立好。
接下来我们设置应用程序项目PureMilk：
1．使用“/GMA/Temp/Compile/”作为项目编译时使用的中间目录
2．使用“/GMA/Temp/Link/”作为项目链接的输出目录
首先将配置改成All Configuration（全部配置），这样可以让我们同时修改Debug和Release的部分；
Output Directory（输出目录，链接器）栏位填入：
$(SolutionDir)\Temp\Link\$(ProjectName)\$(ConfigurationName)
Intermediate Directory（中间目录，编译器）栏位填入：
$(SolutionDir)\Temp\Compile\$(ProjectName)\$(ConfigurationName)
3．构建结束后拷贝执行文件到“/GMA/Bin/Release/”或“/GMA/Bin/Debug/”
在Command Line中填入，All配置下：
copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName);
4．调试时运行“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”下面的执行文件，并以“/GMA/Bin/Debug/”或“/GMA/Bin/Release/”为工作目录
Command栏位填入：$(SolutionDir)\Bin\$(ConfigurationName)\$(TargetFileName)
Working Directory栏位填入：$(SolutionDir)\Bin\$(ConfigurationName)\
这样就大功告成了，现在你就可以编译该执行程序并进行调试。
以vs2010为列，一些项目属性截图如下：
一、调试-》命令
如上图设置，如果项目名称为ss，则TargetName系统变量的值就是ss，TargetExt是扩展名为exe，此时单击调试按钮（vs中的那个小三角形按钮），会起动图中所示目录下的ss-XX-.exe文件。
注意：调试栏目下的所有选项都是为了调试服务的，如果不用调试按钮，这些选项就不起作用。至于VC++目录以及C/C++栏目是给编译器起作用的，无法是告诉编译器在哪里寻找头文件、库文件之类的事情，或者设置其他一些编译器选项，此不赘述。
二、链接器-》常规-》输出文件 （表示链接器生成的exe文件放在哪以及生成的exe文件名称）
上图中，如果项目名称为ss，则连接器生成的exe为图中所示目录下的ss-YY-.exe文件。一般来说这个文件的位置和名称要和上面所述的“命令”选项相同，以表示链接器生成的文件和调试时使用的文件一样。（注意调试时如果没有修改源代码操作，单击调试按钮后，为了加快调试速度，并不会对程序重新链接，也即不会启动链接器）
经过我做过的一些实验证明，如果已经通过链接器生成了exe文件，手动修改这个exe文件名，调试时只要将上图所示的选项的文件名也进行相应的修改，一样可以进行调试并启动exe程序。
三、链接器-》输入-》附加依赖项 （此选项是设置程序链接时使用的静态库。相当于链接已经编译好了的“代码”。由此我们可以简单的认为这些库就相当于我们写的.cpp文件，只不过这些库是编译好了的.cpp而已）
最后说一下，在开发过程中，究竟怎样来让 Visual Studio 链接这些 lib 及 dll 文件会比较好呢？
因为，在调试 Visual Studio 2008 程序时，经常有一些动态链接库（即 dll 文件）需要加载到工程里，这样才能依赖第三方库进行程序调试。
这些动态链接库，往往都是测试版本或是开发中的版本，或者会有若干个版本；这个时候，如果直接把 dll 所在目录加到 PATH 里，则会有潜在冲突的危险；如果直接拷贝到 Visual Studio 的目录下，假如测试工程太多，每次有新版本的动态链接库更新时，你需要更新若干次，拷贝、粘贴苦不堪言。
总体上来说，有几种方法可以改变 Visual Studio 的环境变量设置：
- 直接添加到系统的 PATH 变量里：
这个方法最简单，也最直接，但是坏处是会影响全局的 PATH 设置，尤其是你包含着大量测试用的 dll 时。
- 在 Visual Studio 全局设置里，把 dll 所在目录添加到 PATH 里：
通过 Visual Studio 菜单 ==> 工具 ==> 选项 ==> 项目和解决方案 ==> VC++目录，在下拉框里选择"可执行文件"，然后把 dll 所在路径添加进去。
- 直接把所有 dll 拷贝到 Visual Studio 工程目录下，或是拷贝到生成可执行文件的文件夹（默认情况下是 Debug 或 Release 目录）下：
这个方法也很简单，但是当你有若干个工程时，你每次更新 SDK 及其 dll 文件，你就要把所有的工程都更新，这个不符合文件唯一性的工程性准则。
- 在调试程序时，让 Visual Studio 帮你切换当前工作目录到 dll 相应的目录下：
在 Visual Studio ==> Project ==> Properties ==> Select Configuration ==> Configuration Properties ==> Debugging ==> Working directory 里填上 dll 所在目录，这样当在调试程序时，Visual Studio 会把当前工作目录切换到这个目录下，从而会自动读取本目录下的 dll 文件。
这个方法的优点很明显，简单！副作用也很明显，在你切换了当前工作目录后，你可能会找不到程序的配置文件，在程序里写的诸如"./config.ini"全部都找不到了；另外，你要把所有的 dll 都放到这个工作目录里，否则一样会提示说找不到 xxx.dll 的问题。
- 最后一个方法，也是我认为最好的一个方法，在 Visual Studio 工程属性里把一个目录临时添加到 PATH 环境变量里：
MSDN 上也有类似的介绍：How to: Set Environment Variables for Projects，方法很简单，在 "工程属性" ==> "调试" ==> "环境"里，添加类似如下所示的内容：
PATH=%PATH%;$(TargetDir)\DLLS
这样就可以把 $(TargetDir)\DLLS 临时添加到该工程所属的系统 PATH 里。
大家可以根据项目的实际情况，灵活选用以上方法。
附1：vs（主要是.Net）中常用的各种类型的文件：
附：*.ascx *.asax *.aspx.resx *.asax.resx是什么文件
sln：解决方案文件，为解决方案资源管理器提供显示管理文件的图形接口所需的信息。
.csproj:项目文件，创建应用程序所需的引用、数据连接、文件夹和文件的信息。
.aspx：Web 窗体页由两部分组成：视觉元素（HTML、服务器控件和静态文本）和该页的编程逻辑。Visual Studio 将这两个组成部分分别存储在一个单独的文件中。视觉元素在.aspx 文件中创建。
.aspx.cs：Web 窗体页的编程逻辑位于一个单独的类文件中，该文件称作代码隐藏类文件（.aspx.cs）。
.cs： 类模块代码文件。业务逻辑处理层的代码。
.asax：Global.asax 文件（也叫做 ASP.NET 应用程序文件）是一个可选的文件，该文件包含响应 ASP.NET 或 HTTP 模块引发的应用程序级别事件的代码。
.config：Web.config 文件向它们所在的目录和所有子目录提供配置信息。
.aspx.resx/.resx：资源文件，资源是在逻辑上由应用程序部署的任何非可执行数据。通过在资源文件中存储数据，无需重新编译整个应用程序即可更改数据。
.XSD:XML schema的一种.从DTD,XDR发展到XSD
.pdb:PDB（程序数据库）文件保持着调试和项目状态信息，从而可以对程序的调试配置进行增量链接。
.suo:解决方案用户选项,记录所有将与解决方案建立关联的选项，以便在每次打开时，它都包含您所做的自定义设置。
.asmx:asmx 文件包含 WebService 处理指令，并用作 XML Web services 的可寻址入口点
.vsdisco（项目发现）文件 基于 XML 的文件，它包含为 Web 服务提供发现信息的资源的链接 (URL)。
.htc:一个HTML文件,包含脚本和定义组件的一系列HTC特定元素.htc提供在脚本中implement组件的机制
.ascx 是用户控件代码文件
.aspx webform html脚本文件
.cs 是c#类文件)
.vb 是vb类文件)
.aspx.cs 和你的webform相关的后台c#代码文件,其实跟.cs是一样的
.aspx.vb 和你的webform相关的后台VB代码文件,其实跟.vb是一样的
web.config 配置文件
.xml xml文件
.css 样式表文件
附2.显示行号
菜单栏点击工具-->选项-->文本编辑器-->C/C++，在右侧“显示”处选择行号。
------------------------------------------------------------------------------------------------------------------------------------
from:https://blog.csdn.net/lp310018931/article/details/49110069
首先，我们一般不会修改解决方案的属性，而是设置每个项目各自的属性.
接着上一篇文章，我们来看看我们应该怎样来设置各项目的项目属性更好：
我们以NYOJ_001项目的Debug版的设置为例：
在常规选项里，我们一般会设置输出目录（即生成.exe文件的目录），中间目录（即中间文件的目录）。当然你也可以在这里设置生成的.exe文件的文件名甚至扩展名等。
如下图所示:
一般设置如下的目录:如果不记得某个宏变量的值，可以点击“宏(M)>>”来查看。
既然我们修改了输出文件的目录，那我们也必须修改我们的调试目录，不然就无法调试了。不信你运行一下试试，虽然编译通过了，但并没像你想的那样出现控制台的“黑窗口”，原因就是我们没有修改调试目录:
将调试目录修改为$(OutDir)就可以了，$(OutDir)就是我们之前在常规里设置的输出文件的目录：
这里面的命令参数一项也是比较重要的，如果你开发的是一个带有命令行参数的项目，你调试的时候就可以在这里设置传给程序的命令行参数来进行调试了。你是否还记得你运行一个带有命令行参数的程序时是出现一个黑框框然后马上就消失了，什么也不会做，除非你是将该程序拖到命令提示符下运行。
这些设置完后，可以先编译运行一下程序，结果如下所示:
程序可以正常调试，还会在解决方案的根目录下生成我们设置的输出文件的目录:Win32\Debug\Bin，生成的.exe文件就在该目录下。还有中间文件目录:Win32\Debug\XXX，里面放的都是生成的中间文件。如果你的这个项目里用到了其他的库，你还需要像下面这样设置你的项目的附加包含目录和附加库目录:前都是设置其他库的.h头文件的目录，一般放在库的include文件夹下。后者是设置其他库的lib以及.dll链接库的目录，一般放在库的lib下。如下:
最后你还必须设置项目的附加依赖项的值:一般设置的就是xx.lib静态链接库的名称
好了，所有必须设置的都已经设置完成了。
下面还有一个非常有用的设置，我们知道当我们的程序使用在其他的库的dll文件时，在程序的当前目录或环境变量指定的目录中必须能够找得到这些.dll文件，即现在我们打开.exe文件所在的Bin文件夹，双击运行程序，除非你设置了所依赖的dll的环境变量，否则程序仍然无法运行，因为程序无法找到dll模块。你可以手动把这些.dll拷贝到.exe文件所在的文件夹，但现在有一个更好的办法，如下图:
我们可以在上面的命令行中填写我们在重新生成完程序后，执行的命令。我们可以在这里使用copy命令，来将程序需要的.dll文件自动拷贝到.exe文件所在的目录。当然，在这里你可以做更多的事情，比如如果你的程序需要读取配置文件，你也可以把配置文件拷贝过来等。
最后，把配置由Debug改变Release再将Release下的所有这些设置重新设置成Debug相同的就可以了。
路径推荐使用编译器提供给我们的宏变量，而尽量不要使用绝对的名称，这样程序更具有移植性。例如，如果某外部库的目录为Win32\Debug与Win32\Release或Win64\Debu与Win64\Release。这样我们使用$(Platform)\$(Configuration)进行设置的时候就不需要再去管什么平台以及是Debug还是Release版本。因为编译器会自动为我们切换，当选择Debug进行编译时，编译器会自动链接到Debug版本，当选择Release进行编译时，会自动链接到Release版本。
还要注意的就是，如果有某些项目是作为导出链接库用的。需要把导出的dll, lib（即输出文件路径）设置到上面的Bin目录下。然后在需要使用导出的dll和lib文件的项目中设置
项目依赖项这前者，并设置附加库目录和附加依赖项。这样可以很方便的使用同一解决方案中其他项目导出的链接库了。