目前的项目依赖于很多第三方库，每次要再一个新的环境编译/运行，都要花很长时间先编译/安装各种第三方库，而且会出现各种问题，因此决定将所有第三方库编译好之后，放入工程的子目录中，以后就不用重复编译了。
目录结构
整理后的目录结构如下：
一些设置
如此修改目录结构之后，VS工程的一些设置需要进行修改，分别说明一下：
输出文件的路径
在工程属性中 Configuration Properties > General > Output Directory 指定的是编译出来的lib/dll/exe存放的路径。
因为需要分平台，分Debug/Release版，所以用到了一些宏：
- $(SolutionDir)表示solution所在的目录，在这里就是src
- $(Platform)是当前编译的平台，win32/x64
- $(Configuration)是当前编译的版本，Debug/Release
修改头文件和库文件的包含目录
相应修改一下就行，使用$(Platform)$(Configuration)这两个宏，可以使各个平台/版本的配置都一样，不需要分开配置。
具体想知道有哪些可以使用的宏，可以再任何一个edit窗口，点击“Macro>>”按钮，展开所有的宏查看。
指定dll所在目录
最后这一条比较重要，因为现在所有第三方库都不用安装了，所以在运行程序的时候如何找到这些dll是一个问题。
exe在运行的时候找dll的顺序如下，理论上把dll加到任何一个环节都可以：
- 应用程序所在目录；
- 系统目录。GetSystemDirectory返回的目录，通常是系统盘\Windows\System32；
- 16位系统目录。该项只是为了向前兼容的处理，可以不考虑；
- Windows目录。GetWindowsDirectory返回的目录，通常是系统盘\Windows；
- 当前目录。GetCurrentDirectory返回的目录；
- 环境变量PATH中所有目录。
我们之前做了这么多事情，就是为了在新的环境中不需要做任何配置就能运行VS的工程，所以任何手动拷文件/修改环境变量的方式都不是最好的。
参考了这篇文章 http://my.oschina.net/u/243648/blog/62847，因为我们的dll分散在很多个文件夹中，最后采取的方法是将这些目录都加到环境变量PATH中，当然不是手动添加，而是加到VS的配置中。
在工程属性中 Configuration Properties > Debugging > Environment 可以添加在VS中运行程序需要添加的一些环境变量，仅对当前工程有效。我们把所有第三方库的路径加进去就行了，注意一定要用相对路径，否则换一台机器还是不能用。这里有个潜在的危险，如果你的系统里面已经装了这个第三方库，并且加到了上面6个环节中的任意一个，可能会引起一些错误。
另外如果出build的话，就需要另写一个脚本，将需要用到的第三方dll和编译出来的程序一起打包，这样就行了。