vs2017+配置工程的编译路径（输出目录和中间目录）

TIPS：以下使用visual C++中Windows桌面向导生成的解决方案为例。且演示的visual studio的版本为2017，即visual studio 2017。

一、说明默认的工程配置编译路径

TIPS：我们在解决方案内新建两个项目。

其中，两个项目project1和project2的编译路径，即输出目录和中间目录均是默认配置。（项目(鼠标右键)→属性→配置属性→常规）

配置：所有配置意味着包括debug和release版本。编译平台为x64，即64位操作系统。

$(SolutionDir)：解决方案名，即.sln所在路径

$(Platform)：解决方案平台名称，如x86、x64

$(Configuration)：当前的编译配置名称，如Release、Debug

$(ProjectName)：当前工程(项目)名称，如示例中的project1，project2

（补充）我们可以在：项目(鼠标右键)→属性→配置属性→常规→输出目录(点击下拉箭头)→编辑→宏中看到相应名称和值的一一对应关系。

然后我们将两个项目均运行编译，打开文件所在路径。

我们发现解决方案Project1中的文件生成结构如上所述。

我们在回想我们之前看到的项目默认配置路径。

默认情况下，跟project1、project2两个项目同级生成的debug是project1和project2的输出目录，即与.sln文件同级目录。

TIPS：解决方案平台默认是x64。所以默认配置情况下$(Platform)的作用透明。

project1、project2的中间目录，通俗的理解就是日志信息，每次编译项目都会增加中间目录所占大小。在默认情况下，中间目录生成路径会在每个项目中均有生成。

总结

这样的结果就会造成其中间目录和输出目录对源码的干扰性很大，当我们需要对源码进行打包发送给其他伙伴、同事的时候，我们本来只有几KB的源码，由于我们的工程中包含输出目录和中间目录使得我们的工程变成了几百MB，这样是非常不友好的。接下来，讲述如何通过手动配置工程编译路径避免这种情况的发生。

二、手动配置编译路径

此处：仍然使用visual C++中Windows桌面向导生成的解决方案为例。且演示的visual studio的版本为2017，即visual studio 2017。

先在解决方案project1中创建两个项目，分别是project1、project2，同上。

但是其输出目录和中间目录，我们选择在x64平台复制其输出目录路径。

$(SolutionDir)$(Platform)\$(Configuration)\

然后将平台切换到所有平台。（这样做意味着不管是x64或者x86平台我们都可进行指定目录生成。）

将复制的路径粘贴到所有平台的输出目录中。同时在$(SolutionDir)后面加入…/bin/。

在中间目录同样粘贴：(SolutionDir)(SolutionDir)(SolutionDir)(Platform)$(Configuration)\，同时在$(SolutionDir)后面加入…/temp/,再加入目标文件名：$(ProjectName)\。

紧接着，点击确定即可。

我们将两个项目进行编译运行，打开文件所在路径。

我们发现经过我们手动配置编译路径，跟解决方案Project1同级的目录下生成了bin、temp目录。

bin目录

Win32意味着我们编译的平台是32位操作系统，对应我们手动配置的$(Platform)。

Debug意味着我们的配置是Debug模式。对应我们手动配置的$(Configuration)。

Debug路径下对应的就是我们的输出目录，其中包括project1、project2项目在debug模式下生成的exe文件及附带文件。

temp目录

Win32意味着我们编译的平台是32位操作系统，对应我们手动配置的$(Platform)。

Debug意味着我们的配置是Debug模式。对应我们手动配置的$(Configuration)。

Project1、Project2就是两个项目生成的中间目录，通俗的说就是项目对应的日志文件信息。对应我们手动配置的$(ProjectName)。

解决方案目录

我们再打开我们的解决方案目录。

发现只有两个项目。

其中项目project1、project2中只保留最基本的配置，以及源码。

总结

我们应当避免其他文件（如输出目录、中间目录等）对程序源码的干扰，为了保证源码管理整洁干净，我们务必手动配置编译输出路径。