Visual Studio项目依赖需显式设置而非自动推断，核心是配置“项目依赖项”并确保被依赖项目在配置管理器中启用生成，同时手动设置包含目录、库目录及平台一致性。
Visual Studio 创建项目时，依赖环境不是“自动配好”的，而是靠后续手动配置项目属性、生成依赖项和平台一致性来落实。不配置，编译阶段就可能报 LNK2019、C1083 或找不到 .lib / .dll —— 尤其当你混用 C++、汇编、静态库或跨平台目标时。
怎么让项目识别并使用另一个项目的输出
核心是设置「项目依赖项」，而不是靠文件路径硬链接。VS 不会自动推断 A 项目用了 B 项目的代码，必须显式声明。
- 在「解决方案资源管理器」中右键点击当前项目 → 选择「项目依赖项」
- 在「依赖于」列表中勾选提供头文件、
.lib或导出符号的项目（比如一个静态库项目） - 确保被依赖项目已启用「生成」：右键该项目 → 「属性」→ 「常规」→ 「配置类型」必须是非空值（如「静态库(.lib)」），且「配置管理器」中该配置的「生成」复选框已勾选
- 依赖关系只影响生成顺序，不自动添加包含目录或库目录——这些仍需在当前项目属性里单独配
AdditionalIncludeDirectories和AdditionalLibraryDirectories
为什么配置了依赖还是提示“无法打开包括文件”
常见于头文件路径未同步。项目依赖项 ≠ 头文件搜索路径继承。即使 A 依赖 B，A 也不会自动把 B 的 $(IntDir) 或源码目录加进自己的包含路径。
Visual Studio Professional 18.8.1
下载
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
- 打开 A 项目的「属性」→ 「C/C++」→ 「常规」→ 「附加包含目录」
- 填入 B 项目的头文件所在路径，推荐用宏：
$(ProjectDir)..\B\include或$(SolutionDir)B\src - 避免写死绝对路径（如
C:\dev\B\include），否则换机器就失效 - 如果 B 是生成中间头文件（如 MIDL 或自动生成的
resource.h），注意检查 B 的「输出目录」是否与 A 的包含路径匹配，且 B 确实先生成成功（看输出窗口是否有1>Generating ...日志）
汇编（MASM）或混合语言项目怎么设依赖
汇编文件本身不参与 C++ 项目依赖链，但若 C++ 代码调用 MyAsmFunc，而该函数定义在 asmfile.asm 中，则必须让 VS 知道这个文件属于当前项目，并启用 MASM 支持。
- 右键项目 → 「生成依赖项」→ 「生成自定义」→ 勾选
masm（不是armasm或ml64，除非你明确用后者） - 把
.asm文件加入项目后，右键该文件 → 「属性」→ 「常规」→ 「项类型」设为Microsoft Macro Assembler - 若汇编代码需要 C++ 的结构体定义，确保对应头文件路径已加到「附加包含目录」；若 C++ 要调用汇编函数，需在 C++ 中用
extern "C" void MyAsmFunc();声明（避免 C++ name mangling） - 注意平台一致性：x64 项目不能引用 x86 汇编生成的
.obj，反之亦然；ml.exe（32位）和ml64.exe（64位）不能混用
配置管理器里“生成”复选框没勾，依赖就白设
这是最隐蔽也最常被忽略的一环。即使你在「项目依赖项」里勾了 B，只要 B 在当前活动配置（如 Debug|x64）的「配置管理器」中「生成」列没打钩，VS 就根本不会去编译 B，自然也不会产出 B.lib 或更新头文件。
- 打开「构建」→ 「配置管理器」
- 找到 B 项目所在行，在「生成」列确认复选框已勾选（灰色不可点 = 该项目未纳入当前解决方案配置）
- 如果 B 是新添加的项目，默认可能未被包含进当前配置，此时要手动勾选，或点击「」创建匹配的项目配置
- 特别注意：解决方案平台（如 x64）和项目平台（如 Win32）不一致时，VS 可能静默跳过该项目生成，且不报错——只在输出窗口显示
Project 'B' not selected to build for this solution configuration.
依赖配置真正生效的前提，是生成顺序、路径可见性、平台对齐、以及配置管理器的显式参与全部到位。少一环，编译器就只能报错，不会猜你想干什么。
