如何让 .NET Linux 应用通过 netcoredeps 本地依赖目录运行而无需在目标机器安装系统库【免费下载链接】core.NET news, announcements, release notes, and more!项目地址: https://gitcode.com/GitHub_Trending/core82/core.NET Core 的 Linux 可移植构建可以在所有受支持的发行版上运行但仍要求在目标设备上安装 CURL、OpenSSL 等第三方依赖库。如果你的用户没有权限在目标机器上安装系统包或者 .NET 的依赖与目标机器上已安装的依赖发生冲突就需要换一种部署方式。从 .NET Core 2.0 开始Linux 应用可以携带第三方依赖的本地副本来运行即使系统范围内已经安装了这些库。本文按 self-contained-linux-apps.md 给出的流程说明如何收集依赖、构建netcoredeps目录并完成部署。先理解加载机制netcoredeps 为什么能生效发布的 .NET Core 应用的主可执行文件即 .NET Core host带有 RPATH 属性值为$ORIGIN/netcoredeps。Linux 共享库加载器在查找共享库时会优先到这个位置查找然后才查默认路径。两个需要注意的边界LD_LIBRARY_PATH环境变量指定的路径、LD_PRELOAD指定的库仍然先于 RPATH 生效。也就是说如果目标机器设置了这两个变量本地依赖目录不会覆盖它们。生效方式是替换式的即使目标机器已安装系统级版本的这些库应用也会使用netcoredeps里的本地副本。准备条件选择最老的受支持发行版作为依赖来源从哪个发行版收集依赖直接决定打包出来的库能跑在哪。文档要求选择应用要运行的最老的受支持发行版作为依赖来源这样可保证打包进去的第三方依赖不会引用只存在于较新 libc / libstdc 中的函数。在来源发行版上操作以下各步最后把结果复制到任意目标机器。用 ldd 收集完整依赖闭包第一步是列出应用根依赖集合用ldd求传递闭包即依赖的依赖逐层展开。根依赖集合包括libcoreclr.so如果应用使用System.IO.Compression.dll程序集System.IO.Compression.Native.so如果应用使用System.Security.Cryptography.dll程序集System.Security.Cryptography.Native.OpenSsl.so、libssl.so.{version}、libcrypto.so.{version}如果应用使用System.Net.Http.dll程序集System.Net.Http.Native.so、libssl.so.{version}、libcrypto.so其中{version}取决于来源发行版来源发行版{version}取值基于 Fedora 的发行版10基于 Debian 9 的发行版1.0.2其他1.0.0拿到第一层依赖后把ldd输出的所有依赖加入清单再对新加入的这些库重复运行ldd直到没有新的依赖出现。未关闭全局化globalization时的额外依赖如果应用没有显式关闭 globalization还要在清单中加入libicuuc.so.{version}、libicui18n.so.{version}、libicudata.so.{version}版本号取来源发行版上实际存在的版本且只取主版本号例如 52.1 就用 52。显式关闭 globalization 的两种文档记载方式在应用的xxxxx.runtimeconfig.json文件中把System.Globalization.Invariant元素设为true或把环境变量CORECLR_GLOBAL_INVARIANT设为1。从清单中剔除标准 C/C 库依赖闭包里会混入系统基础库这些不应打包进netcoredeps。文档给出的基础剔除清单libc.so.*、libm.so.*、libstdc.so.*、libpthread.so.*、linux-vdso.so.*、 libgcc_s.so.*、librt.so.*、libdl.so.*、ld-linux-x86-64.so.*、libresolv.so.*其中libc、libresolv、libstdc是必须剔除的如果不剔除与较新 libc / libstdc 版本编译过的共享库会引发各种奇怪问题。对于以下这些在主流发行版上默认就安装的库文档允许而非要求一并剔除libcom_err.so.2 libcrypt.so.1 libgpg-error.so.0 liblzma.so.5 libuuid.so.1文档说明该列表已在 CentOS、Fedora、openSUSE、Debian、ArchLinux、Slackware、Gentoo、OpenMandriva、Ubuntu 上验证过。部署创建 netcoredeps 目录并放入依赖最终步骤很简单在应用主可执行文件旁边创建一个名为netcoredeps的目录把筛选后的依赖全部复制进去。目录必须与主可执行文件同级RPATH 是相对于可执行文件位置的$ORIGIN移动或重命名目录后应用就找不到本地依赖了。按文档的机制部署完成后应用在两种情形下都应以本地副本运行目标机器未安装这些第三方库、以及目标机器已安装了系统级版本。如果目标机器设置了LD_LIBRARY_PATH或LD_PRELOAD指向别的库路径加载器会先于netcoredeps使用它们排查加载异常时应先确认这两个环境变量。已知限制Fedora 系与其他发行版的根证书位置冲突如果应用用到System.Security.Cryptography.dll或System.Net.Http.dll即需要打包libssl和libcrypto要处理一个文档明确指出的坑基于 Fedora 的发行版把根证书存放在与其他发行版不同的位置而这个位置被硬编码编译进了libcrypto、libssl、libcurl二进制中。文档给出的解决路径有两种发布两个版本的应用分别对应 Fedora 系和其他发行版或者一个应用包带两套依赖在安装或首次运行时检测当前发行版把对应的那套依赖复制到netcoredeps目录。除此之外如果文档中没有覆盖你的具体依赖组合或目标发行版以在来源最老的受支持发行版上实际ldd的结果为准。【免费下载链接】core.NET news, announcements, release notes, and more!项目地址: https://gitcode.com/GitHub_Trending/core82/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何让 .NET Linux 应用通过 netcoredeps 本地依赖目录运行而无需在目标机器安装系统库
如何让 .NET Linux 应用通过 netcoredeps 本地依赖目录运行而无需在目标机器安装系统库【免费下载链接】core.NET news, announcements, release notes, and more!项目地址: https://gitcode.com/GitHub_Trending/core82/core.NET Core 的 Linux 可移植构建可以在所有受支持的发行版上运行但仍要求在目标设备上安装 CURL、OpenSSL 等第三方依赖库。如果你的用户没有权限在目标机器上安装系统包或者 .NET 的依赖与目标机器上已安装的依赖发生冲突就需要换一种部署方式。从 .NET Core 2.0 开始Linux 应用可以携带第三方依赖的本地副本来运行即使系统范围内已经安装了这些库。本文按 self-contained-linux-apps.md 给出的流程说明如何收集依赖、构建netcoredeps目录并完成部署。先理解加载机制netcoredeps 为什么能生效发布的 .NET Core 应用的主可执行文件即 .NET Core host带有 RPATH 属性值为$ORIGIN/netcoredeps。Linux 共享库加载器在查找共享库时会优先到这个位置查找然后才查默认路径。两个需要注意的边界LD_LIBRARY_PATH环境变量指定的路径、LD_PRELOAD指定的库仍然先于 RPATH 生效。也就是说如果目标机器设置了这两个变量本地依赖目录不会覆盖它们。生效方式是替换式的即使目标机器已安装系统级版本的这些库应用也会使用netcoredeps里的本地副本。准备条件选择最老的受支持发行版作为依赖来源从哪个发行版收集依赖直接决定打包出来的库能跑在哪。文档要求选择应用要运行的最老的受支持发行版作为依赖来源这样可保证打包进去的第三方依赖不会引用只存在于较新 libc / libstdc 中的函数。在来源发行版上操作以下各步最后把结果复制到任意目标机器。用 ldd 收集完整依赖闭包第一步是列出应用根依赖集合用ldd求传递闭包即依赖的依赖逐层展开。根依赖集合包括libcoreclr.so如果应用使用System.IO.Compression.dll程序集System.IO.Compression.Native.so如果应用使用System.Security.Cryptography.dll程序集System.Security.Cryptography.Native.OpenSsl.so、libssl.so.{version}、libcrypto.so.{version}如果应用使用System.Net.Http.dll程序集System.Net.Http.Native.so、libssl.so.{version}、libcrypto.so其中{version}取决于来源发行版来源发行版{version}取值基于 Fedora 的发行版10基于 Debian 9 的发行版1.0.2其他1.0.0拿到第一层依赖后把ldd输出的所有依赖加入清单再对新加入的这些库重复运行ldd直到没有新的依赖出现。未关闭全局化globalization时的额外依赖如果应用没有显式关闭 globalization还要在清单中加入libicuuc.so.{version}、libicui18n.so.{version}、libicudata.so.{version}版本号取来源发行版上实际存在的版本且只取主版本号例如 52.1 就用 52。显式关闭 globalization 的两种文档记载方式在应用的xxxxx.runtimeconfig.json文件中把System.Globalization.Invariant元素设为true或把环境变量CORECLR_GLOBAL_INVARIANT设为1。从清单中剔除标准 C/C 库依赖闭包里会混入系统基础库这些不应打包进netcoredeps。文档给出的基础剔除清单libc.so.*、libm.so.*、libstdc.so.*、libpthread.so.*、linux-vdso.so.*、 libgcc_s.so.*、librt.so.*、libdl.so.*、ld-linux-x86-64.so.*、libresolv.so.*其中libc、libresolv、libstdc是必须剔除的如果不剔除与较新 libc / libstdc 版本编译过的共享库会引发各种奇怪问题。对于以下这些在主流发行版上默认就安装的库文档允许而非要求一并剔除libcom_err.so.2 libcrypt.so.1 libgpg-error.so.0 liblzma.so.5 libuuid.so.1文档说明该列表已在 CentOS、Fedora、openSUSE、Debian、ArchLinux、Slackware、Gentoo、OpenMandriva、Ubuntu 上验证过。部署创建 netcoredeps 目录并放入依赖最终步骤很简单在应用主可执行文件旁边创建一个名为netcoredeps的目录把筛选后的依赖全部复制进去。目录必须与主可执行文件同级RPATH 是相对于可执行文件位置的$ORIGIN移动或重命名目录后应用就找不到本地依赖了。按文档的机制部署完成后应用在两种情形下都应以本地副本运行目标机器未安装这些第三方库、以及目标机器已安装了系统级版本。如果目标机器设置了LD_LIBRARY_PATH或LD_PRELOAD指向别的库路径加载器会先于netcoredeps使用它们排查加载异常时应先确认这两个环境变量。已知限制Fedora 系与其他发行版的根证书位置冲突如果应用用到System.Security.Cryptography.dll或System.Net.Http.dll即需要打包libssl和libcrypto要处理一个文档明确指出的坑基于 Fedora 的发行版把根证书存放在与其他发行版不同的位置而这个位置被硬编码编译进了libcrypto、libssl、libcurl二进制中。文档给出的解决路径有两种发布两个版本的应用分别对应 Fedora 系和其他发行版或者一个应用包带两套依赖在安装或首次运行时检测当前发行版把对应的那套依赖复制到netcoredeps目录。除此之外如果文档中没有覆盖你的具体依赖组合或目标发行版以在来源最老的受支持发行版上实际ldd的结果为准。【免费下载链接】core.NET news, announcements, release notes, and more!项目地址: https://gitcode.com/GitHub_Trending/core82/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考