.NET6 Azure Function部署Windows容器遇Python.Runtime.dll加载失败求助

核心排查点及修复动作 #

• 确认程序集加载路径：Azure Function容器的默认程序集探测路径和本地VS环境不同，即便Kudu中能看到Python.Runtime.dll，也可能不在函数的加载路径内。可以在代码中通过Assembly.LoadFrom()指定该DLL的完整物理路径（比如从Kudu查看的D:\home\site\wwwroot\bin\Python.Runtime.dll），替代默认的Assembly.Load()。
• 配置Python环境变量：在Azure Function应用设置中添加以下环境变量，确保pythonnet能定位到嵌入式Python：
  • PYTHONHOME：指向嵌入式Python3.7.3的根目录（例如D:\home\site\python37_embed）
  • PYTHONPATH：设为%PYTHONHOME%;%PYTHONHOME%\Lib\site-packages
• 校验位数一致性：确保Python.Runtime.dll的位数（x86/x64）与Azure Function容器的运行位数完全匹配，同时嵌入式Python也需对应相同位数（比如容器是64位，就用64位的Python3.7.3嵌入式包）。
• 强制复制依赖到输出：在项目的.csproj文件中添加以下配置，确保Python.Runtime.dll和Python嵌入式文件在打包部署时被复制到输出目录：

  <ItemGroup>
    <None Include="Python.Runtime.dll">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
    <None Include="python37_embed\**">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  

方案1：优化pythonnet集成 #

• 放弃依赖NuGet中Numpy包嵌入的pythonnet，单独安装与Python3.7匹配的Python.Runtime NuGet包（如2.5.1版本），手动管理Python嵌入式环境和第三方包（Numpy/Pandas/Scipy），避免版本冲突。
• 在初始化Python引擎前显式配置路径：

  PythonEngine.PythonHome = @"D:\home\site\python37_embed";
  PythonEngine.PythonPath = $@"{PythonEngine.PythonHome};{PythonEngine.PythonHome}\Lib\site-packages";
  PythonEngine.Initialize();
  

方案2：分离式HTTP调用 #

• 单独创建Python版Azure Function，封装Numpy/Pandas/Scipy的计算逻辑，通过HTTP触发暴露接口。
• C# Azure Function通过HttpClient调用该Python函数的HTTP接口，传递JSON格式的输入输出数据。此方案彻底隔离.NET与Python运行时，无程序集加载问题，维护更简单。

方案3：进程外调用 #

• 在C#函数中通过Process.Start()启动独立的Python脚本进程，通过标准输入输出或临时JSON文件传递数据。
• 示例代码片段：

  var process = new ProcessStartInfo
  {
      FileName = @"D:\home\site\python37_embed\python.exe",
      Arguments = "calculation_script.py",
      RedirectStandardInput = true,
      RedirectStandardOutput = true,
      UseShellExecute = false
  };
  using (var p = Process.Start(process))
  {
      p.StandardInput.WriteLine(JsonConvert.SerializeObject(inputData));
      p.StandardInput.Close();
      var output = p.StandardOutput.ReadToEnd();
      var result = JsonConvert.DeserializeObject<ResultModel>(output);
  }
  

• 优点是完全隔离运行时，无依赖冲突；缺点是进程启动有一定性能开销，适合非高频计算场景。

方案4：ML.NET替代（有限场景） #

• 若仅需基础数值计算、数据处理，可使用Microsoft.ML.Numpy包，它提供了类似Numpy的C# API，无需依赖Python。但Scipy的高级科学计算功能无法覆盖，仅适合部分替代场景。

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