phoenix8848cn@qq.com
1. 目的
1. 规范公司的工程配置
2. 有利于代码产品的组织、合并
3. 有利于程序员之间的交流
2. 参与者
所有的代码开发人员，亦适用于实习生
3. 编译版本
一般情况下VC2005配置管理器只需要配置debug与release两个版本，解决方案配置名分别对应“Debug”与“Release”。
若开发人员需要定制不同的debug或release版本时，不应在“工程－属性－配置属性－C/C++－预处理器－预处理器定义”中进行定义，而应在代码中通过#define进行定义，这样该工程被任意引用时都无须级联定义预处理器。只有在需要进行Dll导出时才在此处进行预处理器定义。
系统默认的预处理器通常也不要出现，而使用“从父级或项目默认设置继承”。
4. 目录结构
本地工程的目录结构如下图所示：
MyWork
├─Bin
│ ├─Debug
│ └─Release
├─Build
│ ├─Debug
│ │ ├─Project_1
│ │ └─Project_2
│ └─Release
│ ├─Project_1
│ └─Project_2
├─Include
├─Project
│ ├─Project_1
│ └─Project_2
│ └─Doc
└─Solution
Bin：按编译版本分类存放编译成功后的DLL模块、可执行程序或其它内容。通常除非是操作系统的组件，否则Bin中的模块或程序不依赖于该文件夹之外的任何文件；每一个编译版本的模块或程序都可以独立运行。
若目标模块或工程确需要其它组件，则应使用“工程－属性－配置属性－生成事件”对应的事件功能来输出特定的文件，该文件通常位于该工程代码目录下。例如，模块需要一个“DBService.udl”文件作为数据库连接文件，则应在“工程－属性－配置属性－生成事件－预生成事件－命令”里使用“copy DBService.udl ..\..\Bin\$(CofigurationName)\DBService.udl”命令来输出该文件。
Build：按编译版本与工程名分类存放编译过程的中间文件
Include：工程的公共头文件目录，所有工程输出或包含的头文件均位于此目录下。若工程依赖的头文件较多，如boost库，可以另外存放，通过VC2005的环境配置来包含。若工程输出的头文件较多，可以自行在Include中定义二级或三级子目录，此种情况下工程的开发人员最好提供一个位于Include目录下的“Include_XXX.h”文件，这样用户只需包含此文件便可把Include中相关子目录中的文件一同包含进来。
Project：工程的代码目录。此目录下按模块名字存放工程的代码。需要指出的是，每个模块代码子目录下应视需要包含一个“doc”二级子目录，该目录中主要存放与该模块（仅与该模块）相关的所有设计文档，如UML文档、数据库设计文档、脚本文件、Word文档等，doc二级子目录一般按“主题”组织，比如撰写文档过程中绘制的Visio图表等，一并也应放入，可以起到一个备份作用。通常svn代码管理只管理Project目录。
Solution：存放解决方案。通常每个开发人员会承担一个软件产品不止一个模块的开发，开发人员可根据需要将Project目录中的工程进行组合，作为不同主题的解决方案。要注意每个解决方案都会生成一个相对比较大的.ncb文件，该文件是VC2005开发环境的Intellisense（智能感知）生成的文件，需定理清理。
5. 配置用例
工程配置属性中，应该尽量使用相对路径，因为我们无法保证每个开发人员都将工程资料存放在个人计算机相同的位置。可以灵活地使用VC2005的“宏”。
下面给出一个工程配置的例子，供大家参考
工程－属性
配置属性－常规：
输出目录：..\..\Bin\$(ConfigurationName)
中间目录：..\..\Build\$(ConfigurationName)\$(ProjectName)
C/C++ －常规：
附加包含目录：..\..\Include
警告等级：4级
将警告视为错误：是 （注：通常初次着手编写代码时应将这两项置为最严格的等级，这样可以约束我们写出标准、合格的代码来，我认为“0 errers 0 warnings”是一个目标）
C/C++ －预处理器：
预处理器定义：LIB_MY_DLL
链接器－常规：
输出文件：$(OutDir)\$(ProjectName)_D.dll （debug时）
$(OutDir)\$(ProjectName).dll （release时）
附加库目录：$(OutDir)
生成事件－生成后事件：
命令行： copy my_head.h ..\..\Include\my_head.h
说明：正在输出头文件my_head.h到公共Include目录…