.NET Framework 4.0程序在Linux（Debian10）下通过Wine运行时，DllImport调用C++共享库触发DLLNotFoundException的解决求助

看起来你已经缩小了问题范围到编译环节，我来分享几个针对这个场景的关键排查和修复步骤：

一、优先排查共享库的编译兼容性 #

这是Wine加载so库最常见的坑，尤其是跨架构和编译参数问题：

• 架构必须严格匹配：你的.NET Framework程序是32位还是64位？Wine在Debian 10上默认以32位模式运行（除非你安装了wine64并指定启动），所以你的libgraf.so必须和程序架构一致。用以下命令检查库的架构：

  file libgraf.so
  

  输出如果是ELF 32-bit LSB shared object说明是32位，64-bit则是64位，如果和程序架构不匹配，重新编译对应版本的库。
• 必须添加位置无关代码参数：编译C++共享库时，一定要加上-fPIC参数，否则生成的库无法被动态加载器识别。完整的编译命令示例：

  # 编译源文件为目标文件
  g++ -fPIC -c graf.cpp -o graf.o
  # 链接为共享库
  g++ -shared -o libgraf.so graf.o
  

• 检查库的依赖完整性：用ldd命令查看你的共享库是否依赖其他系统库，确保所有依赖在Debian 10上都已安装：

  ldd libgraf.so
  

  如果输出中有not found的项，安装对应的Debian包（比如缺失libstdc++.so.6就安装libstdc++6）。

二、调整C#代码的DllImport配置 #

Wine对Linux so库的加载规则和Windows DLL略有不同，需要明确指定：

• 直接指定so库文件名，并匹配调用约定：C++默认的调用约定是Cdecl，而.NET的DllImport默认是StdCall，不匹配会导致加载失败或运行崩溃。修改代码如下：

  [DllImport("libgraf.so", EntryPoint = "Method1", CallingConvention = CallingConvention.Cdecl)]
  private static extern int Method1();
  

• 如果你的库导出的是C函数名（会被名字修饰），需要用nm -D libgraf.so查看实际导出的函数名，然后把EntryPoint设置为修饰后的名字，或者在C代码中用extern "C"来避免名字修饰：

  extern "C" {
      int Method1() {
          // 函数实现
      }
  }
  

三、调整Wine的库搜索路径 #

即使把库放到/lib或/usr/lib，Wine可能不会优先搜索这些系统目录，你可以通过以下方式指定：

• 启动程序前设置WINEDLLPATH环境变量，把库所在目录加入搜索路径：

  export WINEDLLPATH=/path/to/your/library/folder:$WINEDLLPATH
  wine your-app.exe
  

• 或者用winecfg手动添加库：打开Wine配置窗口，切换到「库」标签页，点击「添加」，选择你的libgraf.so（也可以尝试重命名为graf.dll后添加）。

四、验证Wine是否能识别库 #

用wine ldd命令检查你的程序是否能找到该库：

wine ldd your-app.exe

如果输出中没有libgraf.so的条目，说明Wine确实没找到，回到前面的步骤检查编译和路径配置；如果有条目但显示not found，则是库的依赖问题。

内容的提问来源于stack exchange，提问作者Mélodie Miollany