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