目录
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.3VS配套工具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 和来编写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 的安装目录下找到VCRuntime140.dll和msvcp140.dll。这个目录一般是“C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT”。
有些开发者一开始可能会被ucrt目录下的四十几个文件吓到，不过还好都不大，打包压缩以后都很小。
4.3VS配套工具Remote Debugger的部署方式
可参考Visual Studio 配套的Remote Debugger 调试工具。这个工具由于要求是“standalone”的，所以就是用此方法部署的。
可以在这里找到：“C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86”。
能够看到之前费力找到的动态库都在里面。
5 总结
核心问题是部署问题，在部署时缺少调用CLI这边的库。
如果是使用的VS和来编写C或C++程序，那么就已经是基于UCRT环境下运行的程序，那么就可以使用ucrt的方式来部署；所需动态库：一部分是自己封装或者调用的第三方dll库；一部分是C/C++程序在win环境下运行所必须依赖的库：通用C运行时库UCRT（安装vc_redist.x64_.exe以及Universal CRT Tools x64之后系统的System32或者SysWOW64文件夹中就存在了对应的dll）；如VCRuntime140.dll/VCRuntime140_1.dll 这是VC运行时库和编译器相关的必备模块，必须存在；如msvcp140.dll 如果你写的程序含有C++标准库的代码，那就必须存在；如ucrtbase.dll和api-ms-**.dll 必须存在。在部署的时候就可以参考VS配套工具Remote Debugger的部署方式，将所需UCRT的dll和自行封装的dll都拷贝到程序可执行文件目录
我出这个问题的时候貌似安装了vc_redist也没有完全解决问题，还补充安装了Universal CRT Tools x64（因为有些客户机上没有ucrtbase.dll），另外还需要把自己所需的dll找到放到可执行文件根目录下才能在PC上运行。
问题根源可能不尽相同，但是原因应该都大差不差。
Win下基于通用C运行库UCRT的部署 - 及 {C++/CLI封装的托管dll被C#工程调用时出现未加载（could not load file or assembly）错误排查}
