目录
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)错误排查}