使用--self-contained发布.NET应用后仍提示需安装.NET的问题

使用--self-contained true参数并指定-r选项发布.NET 6应用后，运行时仍提示缺少.NET安装。排查发现发布文件夹中已包含相关依赖DLL，但运行时的依赖发现机制未能识别，主机追踪日志片段如下：

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的机制是什么？为何本地发布文件夹中的DLL无法被识别，却能读取系统目录中的文件？

一、发布文件夹的依赖查找机制 #

.NET自包含发布的应用，运行时不会直接扫描发布根目录的所有DLL，而是严格按照固定的目录结构查找框架依赖：

• 对于Microsoft.NETCore.App这类核心框架，运行时会在应用目录下寻找shared\Microsoft.NETCore.App\<具体版本号>的子路径，框架DLL必须放置在这个层级结构中才能被识别。
• 日志中显示在发布目录下未找到匹配版本，本质是发布后的目录结构不符合运行时的预期——可能是发布过程未生成正确的子目录，或者手动复制DLL时没有还原这个层级结构。

二、系统目录能被识别的原因 #

系统的C:\Program Files\dotnet是.NET的全局安装路径，安装程序会自动生成标准的目录结构：shared\<框架名称>\<版本号>，完全匹配运行时的查找规则。运行时会优先扫描应用目录，当应用目录找不到时，就会 fallback 到这个全局路径查找符合版本要求的依赖。

三、解决建议 #

• 重新执行正确的发布命令：确保-r参数指定了匹配目标环境的运行时标识符（比如win-x64），且--self-contained true参数生效。正常的自包含发布会自动生成包含shared子目录的完整结构，无需手动复制文件。
• 检查项目配置：查看项目文件（.csproj）中是否存在PublishSingleFile、PublishTrimmed等可能改变发布结构的配置。这类参数会将依赖打包到单个可执行文件或修剪不必要的文件，导致发布目录中缺失标准的框架子结构。

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