.NET发布后additionalProbingPaths配置未生效问题咨询

嘿，我之前维护.NET Core 2.x项目时碰到过几乎一模一样的问题，给你几个经过验证的解决方案，应该能帮你搞定：

• 确认runtimeconfig.json的配置格式与路径正确性
  .NET 2.x对additionalProbingPaths的配置要求很严格，相对路径是相对于应用程序exe所在目录的，Windows下可以用正斜杠或者转义后的双反斜杠。正确的配置示例如下：

  {
    "runtimeOptions": {
      "tfm": "netcoreapp2.1",
      "additionalProbingPaths": [
        "./lib",
        "C:/YourAppPath/lib"
      ]
    }
  }
  

  注意：不要漏掉runtimeOptions这个顶层节点，很多人会直接把additionalProbingPaths放在根节点下，导致配置完全不生效。

• 核心宿主文件绝对不能移至lib目录
  有些文件是.NET运行时加载的核心入口，必须和exe放在同一目录，否则会直接触发加载失败。这些文件包括：

  • 你的应用程序主exe文件
  • runtimeconfig.json（以及runtimeconfig.dev.json，如果是开发环境调试用）
  • hostfxr.dll、hostpolicy.dll这类宿主相关的基础dll
    你可以检查下是不是不小心把这些文件也移到lib里了，移回exe所在目录应该就能解决大部分问题。

• 正确使用命令行参数传递探测路径
  如果你想用命令行传递--additionalProbingPath，要注意这个参数是给dotnet宿主程序用的，不是直接传给你的exe。正确的启动命令应该是：

  dotnet YourApp.dll --additionalProbingPath ./lib
  

  要是直接双击exe或者用YourApp.exe命令启动，这个参数根本不会被识别——因为exe本身不处理这个参数，必须通过dotnet命令来启动应用。

• 检查文件与文件夹权限
  Windows下如果是新建的lib文件夹，或者移动文件后权限被更改，运行程序的用户可能没有读取lib文件夹内文件的权限，也会导致加载失败。你可以右键lib文件夹 → 属性 → 安全，确认当前运行程序的用户拥有读取和执行权限。

• 用诊断工具定位具体问题
  如果上面的方法都没用，建议用诊断工具排查具体的绑定失败原因：

  • 使用dotnet trace收集加载日志：运行dotnet trace collect --process-id <你的应用进程ID>，启动程序触发错误后停止收集，查看生成的trace文件就能知道具体哪个dll加载失败。
  • 使用Fusion Log Viewer（fuslogvw.exe）：这是Windows自带的程序集绑定日志工具，开启后可以详细查看程序集加载的每一步，包括探测的路径和失败的具体原因。

另外提一句：.NET 2.1虽然还在长期支持，但毕竟是比较老的版本，路径探测的逻辑相对局限。如果项目允许的话，升级到.NET 6或以上版本，不仅路径配置更灵活，还能获得更好的性能和安全性。

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