版 本 控 制
| 版本号 | 日期 | 修改者 | 说明 | 备注 |
| 0.1 | 2010.07.13 | phoenix | | |
| 0.2 | 2011.01.12 | phoenix | | |
| | | | | |
| | | | | |
| | | | | |
目 录
1. 引言... 1
1.1. 编写目的.. 1
1.2. 参考资料.. 1
2. 目录结构... 1
3. 工程配置... 2
4. 属性配置... 2
4.1. “常规”配置.. 2
4.2. “调试”配置.. 2
4.3. “C/C++”配置.. 3
4.4. “链接器”配置.. 3
4.5. “生成事件”配置.. 3
5. 附录：VC2005中可以使用的宏... 3
当开发人员开始进行编码工作以及编码工作的过程中，都需要根据工程的需要配置各种工作路径，如引入第三方库、输出生成的头文件和库文件等。以前部分开发人员对工程路径的定义比较随意，相当一部分使用的是绝对路径。如果只是单个开发人员完成一个单一的功能，这种做法看起来没有什么明显的缺点。但是，如果是数个开发人员来合作共同完成一个功能和结构都很复杂的工程时，这种做法的弊端就凸显出来。一个非常明显的问题就是：开发人员A将他的工程交给开发人员B编译时，如工程定义使用了绝对路径，除非开发人员B的计算机与A的计算机具有完全相同的文件组织结构，否则一次性编译通过是不可能。另外，当开发人员在一长串的“Can’t find …”或者“XXX undefined”的错误与警告中焦头烂额时，也许只是因为一个不起眼的地方使用了绝对路径，或者是大小写的差异。
因此，规范开发人员的工程配置是很有必要的。通过规范的工程配置，所有开发人员之间的工程是无缝衔接的，即任何一个开发人员的工程拿到其他人的工程时，无须修改任何一个配置便可以一次性的编译成功。这样的规范操作无异可以大大减少团队成员通过代码交流时的不必要成本。另外，规范的工程配置也便于SubVersion版本控制系统的引入，通过引入SubVersion版本控制系统，可以协调整个研发团队的工程进度，控制产品的里程碑发布。这一切，都从规范的工程配置开始。
1. 《OpenSource SubVersion规范》
2. 《Visual Studio 2005编程指南》
MyDevelopeFolder
├─Bin
│ ├─Debug
│ ├─Program
│ ├─Release
│ ├─UnicodeDebug
│ ├─UnicodeProgram
│ └─UnicodeRelease
├─MySDK
│ ├─Include
│ │ ├─BCG
│ │ └─Boost
│ └─Lib
│ ├─Debug
│ │ ├─BCG
│ │ └─Boost
│ ├─Program
│ │ ├─BCG
│ │ └─Boost
│ ├─Release
│ │ ├─BCG
│ │ └─Boost
│ ├─UnicodeDebug
│ │ ├─BCG
│ │ └─Boost
│ ├─UnicodeProgram
│ │ ├─BCG
│ │ └─Boost
│ └─UnicodeRelease
│ ├─BCG
│ └─Boost
├─Project
│ ├─LibMyExample
│ │ └─Document
│ └─MyExampleApp
│ └─Document
├─Solution
└─Temp
├─Compile
└─Link
1. MyDevelopeFolder是开发工程的根目录
2. Bin目录存放所有动态链接库和可执行程序，包括自己的产出和第三方库，按编译配置名称包括对应的子目录，如Debug、Release。另外，程序运行过程中需要外部的数据文件和启动时需要的配置文件等等都可放于该目录
3. MySDK存放产品项目依赖、产出的.h文件和.lib文件。其中Lib目录下根据配置名称和第三方库名称对lib文件进行管理。如某项目使用BCG作为界面库，则BCG的头文件放置于“Include\BCG”下，不同版本的库文件置于“Lib\配置名\BCG”下；项目输出的lib文件直接位于“Lib\配置名”下。这样产品依赖的不同开发库所使用头文件与库文件和输出的头文件与库文件相互之间是独立、彼此不干涉的。
4. Project是工程目录，用于存放代码，按模块名组织次级目录。功能库工程一般的以“Lib”开头，以便与其它动态库区别。每个工程模块目录应包含“Document”子目录，该目录下按需要增加“DBM”、“DOC”、“UML”三个子目录。“DBM”用于存放与该模块相关的数据库设计文档，通常是PowerDesigner文档；“DOC”用于存放与该模块相关的一般性说明文档；“UML”用于存放与该模块相关的UML设计文档，通常是Rational Rose文档。
5. Solution是解决方案目录，用于存放产品的完整解决方案。通常使用解决方案可以生成该产品的所有版本。
6. Temp是用于编译生成的中间目录，主要存放编译过程中生成的各种中间文件。
根据调试信息与字符集的不同，一般的工程配置有六类，如下表所示
| 名称 | 字符集 | 是否包含调试信息 | 是否包含代码优化 |
| Debug | ANSI | YES | NO |
| Release | ANSI | YES | YES |
| Program | ANSI | NO | YES |
| UnicodeDebug | UNICODE | YES | NO |
| UnicodeRelease | UNICODE | YES | YES |
| UnicodeProgram | UNICODE | NO | YES |
输出目录： ..\..\Temp\Link\$(ProjectName)\$(ConfigurationName)
中间目录：..\..\Temp\Compile\$(ProjectName)\$(ConfigurationName)
如果需要启动本模块进行调试，则“命令”为：..\..\Bin\$(ConfigurationName)\$(TargetFileName)
1) “附加包含目录”：..\..\MineSDK\Include ，如有其它目录请用“;”间隔，注意使用相对路径，严禁使用绝对路径。
2) 动态库使用导出宏导出/导入时，应在“预处理器”中定义导出宏，不得在代码文件中定义。导出宏的一般格式为“LIB_XXXXX”。
3) 一般情况下不推荐使用预编译头。
1) “输出文件”：
a) 若为Debug版时：$(OutDir)\$(ProjectName)D.dll；
b) 若为Release版时：$(OutDir)\$(ProjectName).dll。
2) “附加库目录”：..\..\Bin\$(ConfigurationName);..\..\MySDK\Lib，如有其它目录请用“;”间隔，注意使用相对路径，严格禁止使用本地绝对路径。
3) “模块定义文件”：一般不使用模块定义.def文件，本项可选择“从默认配置…”。
一般需要配置的是“生成后事件”。任何一个工程模块的生成后事件都应包括以下内容：
1) copy $(TargetPath) ..\..\Bin\$(ConfigurationName)
2) 若有导出的Lib库文件，需要增加：copy $(TargetDir)$(TargetName).lib ..\..\MySDK\Lib
3) 若有导出的头文件，需要增加： copy myhead.h ..\..\MySDK\Include
具体文件名与路径视情况而定，但是严禁使用绝对路径。
| ConfigurationName | 配置名字，通常是Debug或者Release |
| IntDir | 编译器使用的中间目录，产出obj文件 |
| OutDir | 链接器使用的输出目录 |
| ProjectDir | 项目目录 |
| ProjectName | 项目名字 |
| SolutionDir | 解决方案目录 |
| TargetDir | 目标输出文件所在的目录 |
| TargetExt | 目标输出的扩展名 |
| TargetFileName | 目标输出文件名，包括扩展名 |
| TargetName | 目标输出名，不包括扩展名 |
| TargetPath | 目标输出文件的全路径名 |