正如本主题所建议的，即使使用“--self-contained true”（并使用特定的-r选项）发布，运行时仍会要求提供缺少的.net安装。
现在我已经研究了这个主题，在我看来，几乎所有相关的dll都应该在输出文件夹中，但是由于某种原因，试图发现它们的机制没有找到它们。这可以在跟踪日志中看到，该日志是按照下面的说明应用的：
https://github.com/dotnet/runtime/blob/main/docs/design/features/host-tracing.md
下面是一段跟踪记录：
Resolving FX directory, name 'Microsoft.NETCore.App' version '6.0.0'
Multilevel lookup is true
Searching FX directory in [C:\Program Files\My Application]
Attempting FX roll forward starting from version='[6.0.0]', apply_patches=1, version_compatibility_range=minor, roll_to_highest_version=0, prefer_release=1
'Roll forward' enabled with version_compatibility_range [minor]. Looking for the lowest release greater than or equal version to [6.0.0]
No match greater than or equal to [6.0.0] found.
'Roll forward' enabled with version_compatibility_range [minor]. Looking for the lowest release/pre-release greater than or equal version to [6.0.0]
No match greater than or equal to [6.0.0] found.
Framework reference didn't resolve to any available version.
Searching FX directory in [C:\Program Files\dotnet]我甚至尝试将所有存在于相应 *C：\Program Files\dotnet\shared... * 中的相同文件复制到我的发布文件夹中，但没有更好的结果。
我的主要问题是.NET从发布文件夹中找到dll的机制是什么？为什么它不在发布文件夹中找到它们，而是在 *C：\Program Files\dotnet\shared... *
1条答案
按热度按时间jq6vz3qz1#
显然我花了更多的时间来研究这个。
在我看来，上面的事情发生的原因之一是我使用了dotnet发布--no-build选项，并使用msbuild单独构建。我没有确凿的证据证明这一点，但当我浏览了大量不同的谷歌搜索结果时，有人提出了类似的建议。
但尽管如此，我还是设法使部署工作起来了（这意味着不需要全局.NET安装）。
之后，运行时会将.NET程序集作为自包含的程序集来查找。实际上，在article中提到了 *.runtimeconfig.json只用于依赖于框架的程序集。仍然令人不解的是，为什么dotnet发布会将那个程序集复制到输出文件夹中。但正如上面提到的，我怀疑--no-build选项在某种程度上是相关的。