C++项目开发中是否应当避免在项目间使用Project References？

核心结论 #

Project References不属于不良实践，是C++多项目开发中官方推荐的依赖管理方案，你遇到的链接错误完全是解决方案配置有误导致，无需退回到手动指定#include目录和链接库的旧方案。 #

常见错误原因 #

你遇到的Release构建时查找dependency_d.lib的问题，通常是以下配置疏漏导致：

• 项目命名规则不统一：依赖项目Debug版本输出库文件名固定带_d后缀，Release版本不带，但项目引用没有关联不同配置的输出规则，导致Release构建时仍在查找Debug版本的库文件
• 配置/架构不匹配：主项目切换到Release/x64配置时，被依赖的关联项目没有同步切换到对应配置，仍然生成Debug版本的输出文件
• 输出路径配置错误：依赖项目的对应配置输出路径没有加入主项目的链接器搜索目录，导致链接器无法找到正确版本的库文件

不建议退回手动配置方案的原因 #

手动指定#include目录和链接库的方案出错概率远高于Project References，存在明显缺陷：

• 多配置多架构场景下需要手动维护全项目的配置项，每次新增编译配置（如RelWithDebInfo、交叉编译架构）都要逐个修改项目设置，大型项目极易出现遗漏
• 无法触发依赖项目的自动增量构建：修改依赖项目代码后，主项目构建不会自动编译更新依赖项目，大概率会链接到旧版本的库文件
• 依赖关系不直观：后续开发者无法直接通过解决方案视图查看项目间的依赖关系，维护成本极高

现有问题的修复方案 #

• 统一全局输出规则：所有项目的同配置同架构输出路径统一设置为/bin/$(Platform)/$(Configuration)，中间生成文件路径统一设置为/obj/$(Platform)/$(Configuration)，库文件命名规则全局统一，Debug版本自动添加_d后缀，Release版本不带后缀
• 校验Project Reference配置：逐个检查每个项目引用的属性，确保勾选「使用依赖项目的输出」选项，不同配置、不同架构的引用关联正确，禁止出现Release配置关联Debug目标的情况
• 清理冗余手动配置：删除所有项目中手动填写的链接器输入依赖库名、冗余的附加#include目录、附加库目录配置，完全交由Project References自动解析

内容的提问来源于stack exchange，提问作者Mr. Boy