NETSDK1094 during ResolveReadyToRunCompilers despite PublishReadyToRun in Directory.Build.props #55507

Describe the bug

Since upgrading to SDK 10.0.301 and onwards, I've had to remove the <PublishReadyToRun> and <PublishReadyToRunEmitSymbols> entries from my Directory.Build.props in favor of -p:PublishReadyToRun=true -p:PublishReadyToRunEmitSymbols=true when performing separate dotnet restore and dotnet publish --no-restore actions despite this working previously in SDK 10.0.204 and earlier versions.

This seems related to the breaking change back in .NET 6: Publishing a ReadyToRun project with --no-restore requires changes to the restore. My .binlog output seems to suggest the ReadyToRun/crossgen runtime pack is not being restored properly for 10.0.9 onwards.

Steps to reproduce

Create a Directory.Build.props with the following at the root of your minimal MyConsoleApp.sln .NET 10 SDK console app solution:

<Project>
	<PropertyGroup>
		<TargetFramework>net10.0-windows10.0.26100.0</TargetFramework>
		<SupportedOSPlatformVersion>10.0.20348.0</SupportedOSPlatformVersion>
		<PlatformTarget>x64</PlatformTarget>
		<LangVersion>14.0</LangVersion>
		<ImplicitUsings>enable</ImplicitUsings>
		<Nullable>enable</Nullable>
		<RuntimeIdentifier>win-x64</RuntimeIdentifier>
		<Platforms>x64</Platforms>
		<EnableNETAnalyzers>True</EnableNETAnalyzers>
		<AnalysisLevel>latest-recommended</AnalysisLevel>
		
		<AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>
		<EmbedUntrackedSources>true</EmbedUntrackedSources>
		<NuGetAudit>true</NuGetAudit>
		<NuGetAuditMode>all</NuGetAuditMode>
		<NuGetAuditLevel>high</NuGetAuditLevel>
		<GenerateAssemblyInfo>true</GenerateAssemblyInfo>
		<EnableTrimAnalyzer>false</EnableTrimAnalyzer>

		<!-- Generate the lock file -->
		<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

		<!-- Restore the exact packages as listed in the lock file -->
		<RestoreLockedMode Condition="'$(ContinuousIntegrationBuild)' == 'true'">true</RestoreLockedMode>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)'=='Release'">
		<Optimize>True</Optimize>
	</PropertyGroup>

	<PropertyGroup Condition="'$(TF_BUILD)' == 'true'">
		<Deterministic>true</Deterministic>
		<DeterministicSourcePaths>true</DeterministicSourcePaths>
		<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
	</PropertyGroup>

	<PropertyGroup Condition="'$(OutputType)' == 'Exe'">
		<SelfContained>true</SelfContained>
		<PublishTrimmed>false</PublishTrimmed>
		<PublishAot>false</PublishAot>
	</PropertyGroup>
</Project>

Create a global.json with the following at the root of your solution:

{
  "sdk": {
    "rollForward": "disable",
    "version": "10.0.302"
  }
}

Run the following dotnet restore command:

dotnet.exe restore MyConsoleApp.csproj --verbosity Normal --runtime win-x64 --binaryLogger:MyConsoleApp_nugetrestore_Release_win-x64.binlog --artifacts-path C:\MyConsoleAppArtifact

Then run the following dotnet publish --no-restore command:

dotnet.exe publish MyConsoleApp.csproj --no-restore --configuration Release --artifacts-path C:\MyConsoleAppArtifact --binaryLogger:MyConsoleApp_publish_Release_win-x64.binlog --runtime win-x64 --self-contained true

Expected behavior

Restores packages and publishes successfully.

Actual behavior

Microsoft.NET.Publish.targets(444,5): Error NETSDK1094: Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. When targeting .NET 6 or higher, make sure to restore packages with the PublishReadyToRun property set to true.

Is this a regression?

This worked previously in SDK 10.0.204 and earlier versions.

Are there any workarounds?

• Remove the <PublishReadyToRun> and <PublishReadyToRunEmitSymbols> entries from Directory.Build.props.
• Use -p:PublishReadyToRun=true -p:PublishReadyToRunEmitSymbols=true when performing any dotnet restore or dotnet publish --no-restore actions.

dotnet --info output

.NET SDK:
 Version:           10.0.302
 Commit:            35b593bebf
 Workload version:  10.0.300-manifests.1641d827
 MSBuild version:   18.6.11+35b593beb

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.20348
 OS Platform: Windows
 RID:         win-x64
 Base Path:   D:\DevOpsBuildAgents\BuildAgent3\_work\_tool\dotnet\sdk\10.0.302\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.10
  Architecture: x64
  Commit:       f7d90799ce

.NET SDKs installed:
  10.0.302 [D:\DevOpsBuildAgents\BuildAgent3\_work\_tool\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 10.0.10 [D:\DevOpsBuildAgents\BuildAgent3\_work\_tool\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 10.0.10 [D:\DevOpsBuildAgents\BuildAgent3\_work\_tool\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 10.0.10 [D:\DevOpsBuildAgents\BuildAgent3\_work\_tool\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  DOTNET_CLI_TELEMETRY_OPTOUT              [1]
  DOTNET_NOLOGO                            [true]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

IDE version

Visual Studio Build Tools 2026 [June 2026 Feature Update (18.7.3)] is present on VM, but not used in scenario

Other details

• Run from the context of self-hosted Azure DevOps Build Pipeline agents running on a Windows Server 2022 Azure VM.
• As discussed above, Visual Studio Build Tools 2026 [June 2026 Feature Update (18.7.3)] is present on the VM, but not used in scenario above.
• Some properties/flags are defined more than once (e.g. <RuntimeIdentifier> and --runtime), this is expected and I've included it, warts and all, for completion sake.