发现很多程序员存在这种做法：把项目依赖的第三方库的lib和dll放在项目目录下，或者复制到输出目录，因为每种配置都有不同的输出目录，所以要复制多份（至少包括Debug和Release两个输出目录），这些做法有很多弊端：
- 放在项目目录下不能把项目自己的内容和第三方内容分开，这会导致一些混乱，比如不知道那些是自己的、哪些可以去官网更新
- 复制到输出目录导致做配置管理的时候不能直接忽略输出目录，从而上传了垃圾文件到版本库
- 复制多份违背配置管理的基本原则：一个东西只在一处
正确的做法是：
- 严格区分自己的文件和第三方文件
- 第三方文件独立目录存放
- 运行配置独立目录存放
- 程序输出独立目录存放
以上原则的主要目的是，能够用最简单的方式忽略不要入库的文件，符合以上原则只需要忽略几个目录即可。
为了实现以上目的，要知道VS的几个配置：
- 【C/C++】组的【附加包含目录】，这个基本都知道，用来指定查询头文件的位置
- 【链接器组】的【常规】的【附加库目录】，用来指定链接时寻找lib和dll的位置（注意不是运行时找dll的位置啊）
- 【链接器组】的【输入】的【附加依赖项】，这就是要链接的库，大家都知道
- 【生成事件】组的【生成后事件】，这是编译成功后执行的命令，直接写dos命令即可，比如把依赖的复制到输出目录，这样程序就可以运行了
- 【调试】组的【工作路径】，默认值是项目路径，修改为依赖的dll所在的位置即可让程序跑起来，但是如果程序需要在工作路径输出文件啊、日志啊什么的，这就不一定合适了，违背了要入库的文件和不要入库的文件不能混在一起这个原则，所以要和生成后事件协作，让程序在合适的工作目录执行
- 另外，多个项目共享的内容也可以直接放在解决方案下，放头文件、配置文件什么的是没有问题的
VS里面有一些常用的宏应该了解一下，比如【$(ProjectDir)】代表项目目录，很多配置项配置的时候旁边有个按钮【宏->】，点开就是所有可用的宏。
另外还有一个技巧：
VS的项目配置编辑的时候可以选择【所有配置】和【所有平台】，从而一次性修改所有配置。
相关的设置的位置：
（这里是结束）