VS2010含第三方库项目迁移至VS2017的问题咨询

我在处理VS版本升级和混合项目依赖问题上有不少经验，结合你的场景，直接解答你的三个核心问题：

1. 迁移时是否必须重新编译所有运行时依赖的第三方DLL？ #

不是绝对必须，但要分情况讨论：

• 如果第三方库是动态链接VC++运行时库（比如依赖MSVCR100.dll这类），那必须用VS2017工具集重新编译——因为不同版本的VC++ CRT（运行时库）在内存管理、异常处理、标准库实现上有差异，跨版本混用很容易导致崩溃、内存泄漏或者加载失败。
• 如果第三方库是静态链接VC++运行时库（编译时把CRT打包进库本身），或者是纯C接口且不依赖CRT的内部逻辑，那通常不需要重编译，只要二进制兼容就能正常调用。
• 回到你的场景：你没法用15.0工具集编译SCOM SDK，那这个SDK大概率是依赖VS2010的动态CRT，这时候你的项目如果和它链接，就会被带入VC10的依赖，这也是你加载DLL失败的核心原因之一。

2. Dependency Walker仅显示指定DLL的依赖库还是会递归显示所有依赖项？ #

Dependency Walker默认会递归解析所有依赖链，包括目标DLL的直接依赖，以及这些依赖库的间接依赖（也就是“依赖的依赖”）。不过要注意两个点：

• 它可能会有一些“假阳性”报错，比如某些延迟加载的库、系统未安装的可选库，或者环境变量配置问题导致找不到的库，但核心的依赖关系（比如CRT版本）是准确的。
• 你看到的VC10库依赖，要么是你的DLL直接链接了VS2010的CRT，要么是它依赖的SCOM SDK（或其他第三方库）链接了VC10的CRT，通过递归依赖传递到你的DLL上。

3. 有没有替代处理方案？ #

针对SCOM SDK无法用VS2017工具集编译的情况，给你几个可行的方向：

方案一：调整C++项目的CRT链接方式 #

把你的C++项目设置为静态链接CRT：

1. 打开项目属性 -> 配置属性 -> C/C++ -> 代码生成
2. 把“运行库”选项改为/MT（Release模式）或/MTd（Debug模式）
   这样你的DLL会把VS2017的CRT直接打包进去，不会依赖动态的VC17运行时，和依赖VC10的SCOM SDK共存时，冲突会大幅降低。但要注意：静态链接后，你不能在项目中混用动态链接的CRT组件（比如某些依赖动态MFC的库）。

方案二：打包VC10运行时库到应用目录 #

把VS2010的VC++ redist库（比如MSVCR100.dll、MSVCP100.dll等）复制到你的应用程序根目录下，这样系统会优先加载本地的VC10库，而不是系统全局的版本。这种方式能快速解决依赖问题，但要确保你有合法分发这些库的权限（微软允许开发者分发VC redist组件）。

方案三：改用COM互操作调用SCOM SDK #

如果SCOM SDK是基于COM的组件，你可以跳过C++项目的直接链接，让C#项目通过COM互操作来调用它：

1. 在C#项目中添加对SCOM SDK COM组件的引用
2. 直接在C#代码中调用SDK的接口
   这样你的C++项目只需要处理自身的逻辑，不会和SCOM SDK的CRT依赖产生冲突，这是隔离依赖的有效方式。

方案四：寻找适配VS2017的SCOM SDK版本 #

去微软官方渠道查询是否有支持VS2017的SCOM SDK更新版本，或者看看NuGet上有没有已经适配新工具集的SCOM相关包——很多微软的SDK都会随着VS版本更新提供兼容包，这是最彻底的解决方式。

内容的提问来源于stack exchange，提问作者Deepak Selvakumar