Question

问题的简短版本：

.NET Core 3中是否可以使用与app.config中<probing>元素相同的规则来指定本地探测路径？ additionalProbingPaths似乎无效。

长版问题：

我要将项目从.NET Framework迁移到.NET Core3。在原始项目中，我在lib /文件夹中保留了许多辅助dll。当我在App.exe.config中设置探测路径时，效果很好，就像这样：

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="lib" />
    </assemblyBinding>
  </runtime>

但是，将项目转换为.NET Core 3后，该程序将无法运行，并说找不到dll。 App.exe.config仍然存在，并且仍在读取/使用，因为它还包含有关System.Configuration参数的信息，并且程序的该部分仍然可以正常工作。

我确定在App.runtimeconfig.json中有一个新的json文件，用于存储程序的配置信息。它是自动生成的，默认情况下不包含其他探测路径，但是App.runtimeconfig.dev.json文件包含一些探测路径。

现在，我无法使用.dev.json文件中的路径，因为这些路径指向本地用户目录，并且不能被部署。但是，我可以使用项目目录中的模板文件（runtimeconfig.template.json）将自己的版本添加到主runtimeconfig中。这会将属性添加到主runtimeconfig文件中的runtimeOptions分组中。模板代码为：

{
  "additionalProbingPaths": [
    "lib"   
  ]
}

App.runtimeconfig.json文件的最终输出是：

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.WindowsDesktop.App",
      "version": "3.0.0-preview6-27804-01"
    },
    "additionalProbingPaths": [
      "lib"
    ]
  }
}

但是，无论是使用模板将其插入到主runtimeconfig文件中，还是只是手动编辑dev.json文件，似乎都没有使用我插入的相对路径。我还尝试了如何指定目录的多种方式。程序始终会生成一条错误消息，指出如果该程序集不在根程序目录中，则找不到该程序集。该错误表明它正在寻找从lib/netstandard2.0/HtmlAgilityPack.dll文件中获取的App.deps.json（或其他类似的库）。

解决方法是让所有库都位于根程序目录中，但是由于以前曾经可以使用，所以我期望现在可以正常工作，所以我想知道我做错了尝试在Visual Studio中使用诊断输出获取更多信息失败，因为该程序会在生成任何诊断信息之前终止。

Answer 1

因此，基于从this Github issue获得的信息，我发现在.NET Core中没有等效于<probing>的{{1}}元素的电流。因此，没有简单的“将所有这些.dll放入子目录并从那里工作”的解决方案。

但是，如上所述，可以使用app.exe.config伪指令进行一些其他调整。

首先，将模板文件中的additionalProbingPaths目录设置为“ bin”之类的内容。这将定义新程序集存储位置的根，该位置将被构造为类似于NuGet存储库。

然后在构建后事件中设置命令，以将additionalProbingPaths文件移动到HtmlAgilityPack.dll中。完整路径由"$(TargetDir)bin/HtmlAgilityPack/1.11.8/lib/netstandard2.0"文件中提供的组装信息的两半构成：deps.json和位于"HtmlAgilityPack/1.11.8"小节下的"lib/netstandard2.0/HtmlAgilityPack.dll"。然后，普通的依赖项解析过程将能够根据"runtime"文件中的内容以及deps.json的探测路径来找到它。

此外，复制为生成后生成的命令，并使用bin而非<Target Name="PostPublish" AfterTargets="Publish">在.csproj文件（$(PublishDir)）中创建另一个Target元素，以进行定义输出。这样一来，构建系统就可以在发布和构建时执行相同的文件移动。

这确实意味着每次更新软件包版本号时都要更新文件移动命令，因此需要进行额外的手动工作才能使其保持最新状态。

我<希望>他们他们将改进构建系统以自动执行类似的操作，因为除了清理工作之外，它还为多种版本的依赖项提供了选择，并可能有助于.NET中持续存在的版本问题。

.NET Core 3迁移的其他探测路径

1 个答案: