为何我的.NET runtimeconfig.json引用6.0.8运行时而非6.0.0？

核心问题 #

解决方案包含ASP.NET API和多个ConsoleApp（WebJobs）项目，部署至Azure App Service时，Azure DevOps Ubuntu代理构建出的API.runtimeconfig.json引用.NET 6.0.8运行时，而本地（Win10 + Rider 2022.2 + .NET SDK 6.0.400）构建生成的是6.0.0。由于Azure App Service暂未部署6.0.8运行时，导致API无法启动，需定位根本原因。

可能的根源及验证步骤 #

1. 构建代理的.NET SDK版本差异 #

.NET SDK版本与运行时版本存在固定对应关系：

• 6.0.400 SDK 对应 .NET 6.0.0 运行时
• 6.0.408 SDK 对应 .NET 6.0.8 运行时

验证步骤：
在Azure DevOps Pipeline中添加步骤，打印代理的SDK版本：

- script: dotnet --version
  displayName: 'Check .NET SDK Version'

如果代理使用的是6.0.408或更高版本，这就是导致runtimeconfig引用6.0.8的直接原因。

2. ConsoleApp的RuntimeIdentifier传递影响API项目 #

ConsoleApp项目指定了<RuntimeIdentifier>win-x64</RuntimeIdentifier>，而构建在Ubuntu代理上进行。当构建整个解决方案时，RID可能会被隐式传递给API项目，导致跨RID构建时运行时依赖解析逻辑变化，拉取了对应RID的高版本运行时包。

验证步骤：

• 在Pipeline中单独构建API项目，查看生成的API.runtimeconfig.json是否引用6.0.0：

  - task: DotNetCoreCLI@2
    displayName: 'Build API Only'
    inputs:
      command: 'build'
      projects: '**/API项目名称.csproj'
      arguments: '--no-restore /p:configuration="$(buildConfiguration)"'
  

• 如果单独构建正常，则说明问题源于多项目构建时的RID上下文传递。

3. 锁定文件（packages.lock.json）的差异 #

项目启用了<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>，本地与构建代理的lock文件可能存在差异：

• 本地lock文件基于portable RID生成，而代理上因为ConsoleApp的win-x64 RID，restore时生成了包含高版本运行时的lock文件。

验证步骤：

• 对比本地和代理生成的packages.lock.json中Microsoft.NETCore.App的版本；
• 在Pipeline的restore步骤中添加--locked-mode参数，强制使用本地提交的lock文件，看是否能保持运行时版本为6.0.0。

4. 构建参数的隐式RID设置 #

构建命令中未显式指定API项目的RID，导致构建过程继承了ConsoleApp的win-x64 RID，进而影响API项目的运行时依赖解析。

验证步骤：
在API项目的.csproj中添加显式的portable RID：

<RuntimeIdentifier>portable</RuntimeIdentifier>

或者在构建API项目时单独指定RID参数：

arguments: '--no-restore /p:configuration="$(buildConfiguration)" /p:RuntimeIdentifier=portable'

重新构建后查看runtimeconfig版本是否恢复为6.0.0。

总结 #

最可能的根源是构建代理使用了高于本地的.NET SDK版本，其次是ConsoleApp的RID设置导致跨RID构建时运行时依赖被更新。通过上述验证步骤可快速定位具体原因，从根源上解决问题，而非依赖临时补丁。

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