以下内容为“原创”+“转载”
首先，解决方案和项目文件夹包含关系(c++项目)：
VS解决方案和各个项目文件夹以及解决方案和各个项目对应的配置文件包含关系，假设新建一个项目ssyy，解决方案起名fangan，注意解决方案包括项目，此时生成的最外层目录为fangan代表整个解决方案的内容都在这个文件夹内。在这个fangan文件夹内包含有fangan.sln的解决方案配置文件和一个ssyy文件夹，ssyy文件夹代表整个ssyy项目的所有内容都在这个文件夹内，这个文件夹内含有ssyy.vcproj的项目配置文件和.h头文件以及.cpp源文件。如果在fangan解决方案下再建立一个新项目名为ssyy2，则会在fangan文件夹下生成一个ssyy2文件夹存放ssyy2项目的所有内容。
由上面叙述可以总结出，管理器（解决方案或项目）都会对应一个总的文件夹，这个管理器文件夹下存放本管理器的配置文件以及子管理器。比如，解决方案是个管理器，它的文件夹下含有.sln配置文件以及子管理器ssyy项目和子管理器ssyy2项目。
另外，默认情况下，项目属性设置的目录起点为项目配置文件所在位置，实际上就是项目头文件和源文件所在位置。
补充：vs中建立默认的C#项目和建立默认的C++项目生成的目录结构是不一样的。如果是C#项目，则解决方案总文件夹下就只包含解决方案配置文件sln和一个项目总文件夹(共两个东东)，而项目总文件夹下包含c#源文件、项目配置文件proj、一个Properties属性文件夹、一个obj文件夹和一个bin文件夹，其中obj和bin文件夹下都包含debug和release两个文件夹。obj文件夹下存放中间编译结果（扩展名更加项目类型而不同），而bin文件夹下存放最终生成的结果（扩展名一般为exe或dll）。
而如果是C++项目，则解决方案总文件夹下就只包含解决方案配置文件sln和一个项目总文件夹和一个Debug文件夹以及一个Release文件夹（共四个东东，其中Debug和Release文件夹中存放最终生成的结果exe或dll，要注意如果不使用Release生成，则不存在Release文件夹），而项目总文件夹下包含C++源文件头文件、项目配置文件和一个Debug文件夹以及一个Release文件夹（一定要注意，此处的Debug和Release文件夹仅仅存放中间编译结果obj，不存放exe和dll之类的东西。如果不使用Release编译，则没有对应的Release文件夹）。
由此可见，c#项目默认生成的文件目录结构更合理，且输出的exe位于总项目文件夹内，而c++项目默认exe位于解决方案总文件夹下。另外c#更合理在，C#使用Bin目录，在Bin目录下包含debug和release两个目录，而C++不使用Bin目录，直接使用debug和releae两个目录。
其次，常用项目属性和系统配置变量关系：
如果我们建立一个默认的vc项目ssyy，他的默认“常规“栏目中，“输出目录”为$(SolutionDir)$(ConfigurationName)，所以调试时会在解决方案文件夹下建立一个debug（ConfigurationName的值为debug）文件夹，并在此文件夹下生成 ssyy.lik链接器 和ssyy.exe文件 。默认“中间目录”为$(ConfigurationName)，所以会在ssyy项目文件夹下（即ssyy.vcproj的项目配置文件所在位置）建立一个debug文件夹，并在该文件夹下生成ssyy.obj二进制文件。默认“链接器”栏目下的“常规”选项下的“输出文件”选项为$(OutDir)$(ProjectName).exe，其中$(OutDir)就已经在“常规”栏目的“输出目录”选项赋值了。【所以$(OutDir)的值是在“输出目录”属性中定义的】。
另外，经过实际测试，发现“输出目录”属性只能起到对$(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:b.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)TempLink$(ProjectName)$(ConfigurationName)
Intermediate Directory（中间目录，编译器）栏位填入：
$(SolutionDir)TempCompile$(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)TempLink$(ProjectName)$(ConfigurationName)
Intermediate Directory（中间目录，编译器）栏位填入：
$(SolutionDir)TempCompile$(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 里。
大家可以根据项目的实际情况，灵活选用以上方法。
方便自己查找。
转载：
http://blog.csdn.net/yyhero1/article/details/19272637