Azure Linux App Service上.NET 6调用自定义共享库报错‘文件不存在’

问题描述 #

我在ASP.NET Core .NET 6应用中使用原生代码库，已编译Windows版DLL和Linux版.so文件，通过DllImport特性调用。该应用在本地Windows及Ubuntu虚拟机中运行正常，但部署到Azure Linux App Service（Linux）时出现错误：

Unable to load shared library 'mylib' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libmylib: cannot open shared object file: No such file or directory

应用通过Azure DevOps Pipelines部署，发布参数为：

arguments: '--configuration $(BuildConfiguration) -r linux-x64 --self-contained true --output $(Build.ArtifactStagingDirectory)'

Azure DevOps Pipelines可正常运行包含调用原生库的单元测试。通过SSH和Bash检查Azure App Service文件系统，确认libmylib.so存在于编译后的.NET代码目录中，尝试复制到/usr/local/lib仍未解决问题。请问如何在Azure App Service中成功调用该文件？报错是否因缺少其他依赖导致？

原因分析与解决步骤 #

1. 排查.so库的依赖项缺失 #

Azure Linux App Service的基础镜像可能缺少libmylib.so依赖的系统库。执行以下命令查看依赖链：

ldd /home/site/wwwroot/libmylib.so

如果输出中有not found的项，说明存在缺失的系统依赖。解决方式：

• 若App Service计划支持root权限，可在部署脚本中添加安装命令：

  apt-get update && apt-get install -y [缺失的库名]
  

• 若无法获取root权限，可将缺失的系统库打包到应用目录，然后设置LD_LIBRARY_PATH指向该目录。

2. 修正DllImport配置与环境变量 #

确保DllImport的路径和环境变量设置正确：

• 直接指定.so文件的相对路径（避免系统自动查找的歧义）：

  [DllImport("./libmylib.so", CallingConvention = CallingConvention.Cdecl)]
  

• 在Azure App Service的配置-应用设置中添加环境变量，将应用目录加入库搜索路径：

  LD_LIBRARY_PATH = /home/site/wwwroot
  

3. 验证.so库的架构兼容性 #

确认编译的libmylib.so为x64架构，与Azure Linux App Service的linux-x64运行时匹配。执行以下命令检查：

file /home/site/wwwroot/libmylib.so

输出需包含x86-64字样，若为arm等其他架构，需重新编译对应版本的.so文件。

4. 确保部署时文件正确复制 #

检查项目部署配置，保证libmylib.so被完整复制到输出目录：

• 在项目文件（.csproj）中添加以下配置：

  <ItemGroup>
    <None Update="libmylib.so">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  

• 确认Azure DevOps Pipeline的发布步骤中，输出目录的.so文件被完整部署到App Service。

5. 使用LD_DEBUG定位详细错误 #

设置LD_DEBUG环境变量获取加载日志：
在Azure App Service的应用设置中添加：

LD_DEBUG = all

重启应用后，查看日志-日志流，会输出完整的库加载过程，可精准定位失败环节。

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