Visual Studio C++项目工具集从2013升级到2022时的依赖项处理咨询
升级跨版本MSVC工具集确实会遇到一堆依赖兼容的头疼问题，我来针对你的几个核心疑问给出实际的建议：
1. 无源码的第三方厂商库（MSVC2013编译）：隔离风险优先
你提到这些库只处理小功能、暴露简单类型/类，这种情况下短期内大概率能正常运行——但这是“侥幸”而非“安全”。MSVC2013（v120）和2022（v143）的ABI本质不兼容，不过如果库的接口满足以下所有条件，风险会低很多：
- 只暴露POD类型、C风格函数接口
- 类仅包含虚函数（无非标准布局成员、无STL容器成员）
- 没有跨模块的内存分配/释放交叉调用（比如库内部用
malloc，你的代码用delete释放库返回的指针）
但隐藏的风险随时可能爆发（比如系统更新、代码变更触发内存布局错误），更稳妥的方案是做隔离封装：把对这些旧库的所有调用逻辑，单独放到一个用MSVC2013编译的中间DLL里，主程序（MSVC2022）只和这个中间DLL通过C风格或严格ABI兼容的接口通信。这样把旧ABI的风险完全隔离在单独模块里。
2. DirectShow依赖旧WinSDK：用Win7 SDK保留支持
新Windows SDK确实移除了DirectShow，但你可以直接下载Windows SDK for Windows 7 (版本7.1)——它包含完整的DirectShow头文件、库和工具。在VS2022中，你可以给依赖DirectShow的项目单独配置SDK版本为7.1：
- 右键项目 → 属性 → 常规 → Windows SDK版本，选择7.1
如果其他项目用新SDK，务必把DirectShow相关的代码完全隔离在这个用旧SDK编译的项目/模块里，避免头文件和宏定义冲突。如果迁移到Media Foundation成本太高，这个方案是工业界老项目的通用做法，长期可行。
3. 有源码/2022预编译包的依赖：优先自己编译
哪怕有官方提供的MSVC2022预编译包，我也推荐用你的项目的编译/链接选项重新编译源码——因为预编译包的默认选项很可能和你的项目不一致，而选项差异会直接破坏ABI。
如果一定要用预编译包，必须严格核对以下关键选项是否和你的项目完全一致：
- Runtime Library选项：
/MD（多线程DLL）、/MDd（调试多线程DLL）、/MT（多线程静态）、/MTd（调试多线程静态）——这个是ABI兼容的核心，必须完全匹配，否则内存分配器、STL实现都会冲突。 - 结构体对齐：
/Zp选项（比如/Zp4、/Zp8），不一致会导致结构体内存布局错位。 - 异常处理：
/EHscvs/EHa，不同设置会影响函数调用栈和异常处理逻辑。 - 调试/发布模式：预编译包的DEBUG版本不能和你的RELEASE项目混用，反之亦然（DEBUG版有额外的内存检查逻辑，ABI不同）。
- C++语言标准：比如
/std:c++17vs/std:c++20，MSVC尽量保持STL ABI兼容，但仍有潜在风险。
只要以上任何一个关键选项不匹配，直接用预编译包大概率会出现运行时崩溃、内存 corruption 等问题。
4. MSVC14x工具集的ABI兼容性：选项决定一切
MSVC14.x系列（140到143）的基础ABI是兼容的，但编译/链接选项会直接打破这种兼容性——哪怕都是v143工具集，选项不同就可能导致ABI不兼容。比如：
- 你用
/MT静态链接 runtime，而预编译包用/MD动态链接，两者的STL容器内存布局、内存分配器完全不同，跨模块传递STL容器必然崩溃。 - 你开启了
/Zp8对齐，预编译包用默认的/Zp4，结构体的成员偏移会错位，传递结构体参数会导致数据错误。
所以，同工具集下也不能随便混用预编译包，必须保证关键编译选项完全一致。
总结优先级
- 隔离无源码旧库，用中间DLL降低ABI风险
- 用Win7 SDK 7.1保留DirectShow支持，隔离相关代码
- 可控依赖优先自己编译，严格匹配选项
- 对所有涉及跨模块调用的逻辑做充分边界测试
内容来源于stack exchange
