Win下基于通用C运行库UCRT的部署 - 及 {C++/CLI封装的托管dll被C#工程调用时出现未加载（could not load file or assembly）错误排查}_universal crt tools

目录

C++/CLI封装的托管dll被C#工程调用时出现未加载（could not load file or assembly）错误排查及基于通用C运行库UCRT的部署

0 问题分析

1 用于排查的工具

depends

Everything

2 缺少的dll

3 Universal CRT Tools x64

4 基于通用C运行时库—Universal CRT的程序部署

4.1 部署-把依赖库放在自己程序目录下，既不会跟别的应用软件冲突，又方便了软件分发

4.2 UCRT和UMP的相关dlls

4.3 VS配套工具Remote Debugger的部署方式

5 总结

---

C++/CLI封装的托管dll被C#工程调用时出现未加载（could not load file or assembly）错误排查及基于通用C运行库UCRT的部署

0 问题分析

a 没有将自己封装的或者第三方的dll拷贝到可执行文件目录下；

b 缺少系统层面的dll，如C运行时库。

1 用于排查的工具

depends

可以查一下报错的dll到底还依赖那些其他的dll，虽然会查出来特别多东西；

Everything

Everything来快速搜索查看本机上是否有这些库，如果没有的话就可以从有的PC上拷贝过来。

2 缺少的dll

我这边发现最后缺少的mfc的几个动态库，还有ucrt的库等：

concrt140d.dll
mfc140ud.dll
msvcp_win.dll
msvcp140d.dll
vcruntime140d.dll
vcruntime140_1d.dll
ucrtbase.dll 等等

3 Universal CRT Tools x64

测试过程中发现安装win10sdk 和以前明确的toolset v141之后能够正常使用，因此测试单独删除看是否有用。

在排除过程中发现端倪，在安装缓存里找到了Universal CRT Tools x64-x64_en-us.msi和他对应的包05254f60ea43b4e3959b17cdb03268c0.cab，这个单独拿出来安装也是有用的。

 也就是Universal CRT Tools x64-x64.en-us.msi，安装的就是通用C运行时库

 因此考虑到实际使用，将其拷贝出来，提供给用户使用前安装，安装过程提示如下：

 搜索得到Universal CRT Tools x64-x64.en-us.msi对应的数据包：05254f60ea43b4e3959b17cdb03268c0.cab

 找到对应的cab文件后将其复制到和.msi同一目录下，再运行即可正常安装。

 

 安装结束后，可以发现在控制面版中的卸载程序中也出现了Universal CRT Tools x64

 再双击程序即可正常运行。

4 基于通用C运行时库—Universal CRT的程序部署

4.1 部署-把依赖库放在自己程序目录下，既不会跟别的应用软件冲突，又方便了软件分发

可以看这篇文章，讲的比较清楚。

(2条消息) 下一代VC运行时库——Universal CRT_csdn_csdn__AI的博客-CSDN博客

基于UCRT程序的部署方法
Q 什么程序是基于UCRT的？
A 如果你是用Visual Studio 2015和2017来编写C或C++程序，那么就已经是基于UCRT的。

需要关注的程序模块

VCRuntime140.dll 这是VC运行时库和编译器相关的必备模块，必须存在。
msvcp140.dll 如果你写的程序含有C++标准库的代码，那就必须存在。
ucrtbase.dll和api-ms-**.dll 必须存在。 

部署方法

第一种：使用vcredist.exe来给目标机安装相应的文件

......

第三种

现在互联网程序大多使用的是app-local的部署模式，意思就是把依赖库放在自己程序目录下，既不会跟别的应用软件冲突，又方便了软件分发。

4.2 UCRT和UMP的相关dlls

起初，微软并没有打算针对UCRT程序继续这样的部署模式。但是后来大家反响比较强烈，所以在Windows 10 SDK发布的时候，把UCRT和UMP的相关dlls都一起发布了。这个目录一般是“C:\Program Files (x86)\Windows Kits\10\Redist\ucrt”。

你也可以在Visual Studio 2015的安装目录下找到VCRuntime140.dll和msvcp140.dll。这个目录一般是“C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT”。

有些开发者一开始可能会被ucrt目录下的四十几个文件吓到，不过还好都不大，打包压缩以后都很小。

4.3 VS配套工具Remote Debugger的部署方式

可参考Visual Studio 2015配套的Remote Debugger 调试工具。这个工具由于要求是“standalone”的，所以就是用此方法部署的。

可以在这里找到：“C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86”。 

能够看到之前费力找到的动态库都在里面。

5 总结

核心问题是部署问题，在部署时缺少调用CLI这边的库。

1. 如果是使用的VS2015和2017来编写C或C++程序，那么就已经是基于UCRT环境下运行的程序，那么就可以使用ucrt的方式来部署；
2. 所需动态库：一部分是自己封装或者调用的第三方dll库；一部分是C/C++程序在win环境下运行所必须依赖的库：通用C运行时库UCRT（安装vc_redist.x64_2019.exe以及Universal CRT Tools x64之后系统的System32或者SysWOW64文件夹中就存在了对应的dll）；
3. 如VCRuntime140.dll/VCRuntime140_1.dll 这是VC运行时库和编译器相关的必备模块，必须存在；
4. 如msvcp140.dll 如果你写的程序含有C++标准库的代码，那就必须存在；
5. 如ucrtbase.dll和api-ms-**.dll 必须存在。
6. 在部署的时候就可以参考VS配套工具Remote Debugger的部署方式，将所需UCRT的dll和自行封装的dll都拷贝到程序可执行文件目录

我出这个问题的时候貌似安装了vc_redist也没有完全解决问题，还补充安装了Universal CRT Tools x64（因为有些客户机上没有ucrtbase.dll），另外还需要把自己所需的dll找到放到可执行文件根目录下才能在PC上运行。

问题根源可能不尽相同，但是原因应该都大差不差。