Add net12 known framework references

[marcpopMSFT]

Summary

• add the complete live net12.0 known framework and runtime-pack metadata set
• freeze net11.0 package versions and default runtime versions at the public preview 7 build, and snapshot its version-sensitive RID lists
• add explicit net12 RID inheritance boundaries so future runtime flows do not change net11 metadata
• update the annual target-framework rollover guide with the package-version and RID invariants learned from net11

The temporary net11 pins use 11.0.0-preview.7.26381.103 and should move to 11.0.$(VersionFeature110) after .NET 11 GA.

Tracking: #55851

Validation

• full repository build
• GivenUsingDefaultRuntimeFrameworkVersions.DefaultRuntimeVersionsAreUpToDate
• GivenDotNetUsesMSBuild.ItCanNewRestoreBuildRunCleanMSBuildProject
• focused GivenFrameworkReferences and KnownRuntimePackTests coverage
• generated Microsoft.NETCoreSdk.BundledVersions.props inspection for net10/net11/net12 metadata

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Adds the net12.0 “live/current” known-framework-reference contract to the SDK’s bundled metadata generation, while freezing net11.0 versions and RID lists so future net12 dependency/RID growth doesn’t retroactively change net11 behavior. It also updates the annual rollover guide with the key invariants learned from the net11 transition.

Changes:

• Added full net12.0 KnownFrameworkReference / KnownRuntimePack / tool-pack metadata blocks and new Net120* RID inheritance layers.
• Pinned net11.0 runtime/targeting pack versions to preview 7 builds and routed net11 metadata to Net110* RID snapshots.
• Rewrote UpdateToNewTargetFramework.md into a repeatable step-by-step process guide with explicit version/RID isolation rules.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Layout/redist/targets/GenerateBundledVersions.targets	Adds net12 known framework metadata and net12 RID layers; pins net11 pack versions and points net11 entries to version-specific RID lists.
documentation/general/UpdateToNewTargetFramework.md	Updates the rollover guide with sequencing and explicit “freeze N-1 versions/RIDs” invariants.

Suppressed comments (4)

src/Layout/redist/targets/GenerateBundledVersions.targets:884

• The net11 WindowsDesktop framework reference is pinned to a prerelease runtime pack version, but DefaultRuntimeFrameworkVersion is hardcoded to "11.0.0". This can cause resolution of a runtime framework version that doesn't exist for the pinned preview build.

    <KnownFrameworkReference Include="Microsoft.WindowsDesktop.App"
                              TargetFramework="net11.0"
                              RuntimeFrameworkName="Microsoft.WindowsDesktop.App"
                              DefaultRuntimeFrameworkVersion="11.0.0"
                              LatestRuntimeFrameworkVersion="$(_WindowsDesktop110RuntimePackVersion)"

src/Layout/redist/targets/GenerateBundledVersions.targets:896

• The net11 WPF framework reference is pinned to a prerelease runtime pack version, but DefaultRuntimeFrameworkVersion is hardcoded to "11.0.0". This can make the SDK select a default runtime framework version that isn't available for the pinned preview pack.

    <KnownFrameworkReference Include="Microsoft.WindowsDesktop.App.WPF"
                              TargetFramework="net11.0"
                              RuntimeFrameworkName="Microsoft.WindowsDesktop.App"
                              DefaultRuntimeFrameworkVersion="11.0.0"
                              LatestRuntimeFrameworkVersion="$(_WindowsDesktop110RuntimePackVersion)"

src/Layout/redist/targets/GenerateBundledVersions.targets:909

• The net11 Windows Forms framework reference is pinned to a prerelease runtime pack version, but DefaultRuntimeFrameworkVersion is hardcoded to "11.0.0". This can break default runtime framework version selection for framework-dependent scenarios.

    <KnownFrameworkReference Include="Microsoft.WindowsDesktop.App.WindowsForms"
                              TargetFramework="net11.0"
                              RuntimeFrameworkName="Microsoft.WindowsDesktop.App"
                              DefaultRuntimeFrameworkVersion="11.0.0"
                              LatestRuntimeFrameworkVersion="$(_WindowsDesktop110RuntimePackVersion)"

src/Layout/redist/targets/GenerateBundledVersions.targets:922

• The net11 ASP.NET Core framework reference is pinned to a prerelease runtime pack version, but DefaultRuntimeFrameworkVersion is hardcoded to "11.0.0". For prerelease patch-0 versions, the default runtime framework version should remain the full prerelease version to avoid requesting an unavailable GA version.

    <KnownFrameworkReference Include="Microsoft.AspNetCore.App"
                              TargetFramework="net11.0"
                              RuntimeFrameworkName="Microsoft.AspNetCore.App"
                              DefaultRuntimeFrameworkVersion="11.0.0"
                              LatestRuntimeFrameworkVersion="$(_AspNet110RuntimePackVersion)"

[marcpopMSFT]

@jjonescz Could you review and weigh in on the remaining run-file failures in build 1561353? You own this area and the CSharpCompilerCommand behavior, so I’d especially appreciate your guidance on the right fix.

I locally reproduced representative failures from all three groups: RunFileTests_BuildOptions.WorkingDirectory, RunFileTests_BuildCommands.LaunchProfile, and RunFileTests_CscOnlyAndApi.UpToDate. The application output is correct, but the missing warning is a symptom of an unintended fallback to full MSBuild, not an expected-output change.

The mismatch is:

• CSC-only mode derives its inputs from the SDK host runtime, currently 11.0.0-rc.1.26410.101.
• Full MSBuild uses the net11 metadata frozen by this PR at 11.0.0-preview.7.26381.103.
• CSharpCompilerCommand.GetPathsOfCscInputsFromNuGetCache() therefore checks for Microsoft.NET.ILLink.Tasks/11.0.0-rc.1.26410.101.
• That package is absent, so FileBasedAppRunPlan reports Using MSBuild because NuGet package file does not exist... and performs a full build.
• The tests consequently do not receive the expected “MSBuild will be skipped because running just csc is enough” warning. This also means the CSC-only optimization and CSC/MSBuild metadata parity are broken, even though the program output looks fine.

My proposed direction is not to remove the warning expectations or reconnect net11 metadata to the live RC1 properties. Instead, CSharpCompilerCommand should consume the current TFM’s authoritative entries from Microsoft.NETCoreSdk.BundledVersions.props, rather than assuming every target pack version equals the SDK host runtime. At minimum that likely means distinguishing default/latest runtime, targeting-pack, apphost-pack, and ILLink-pack versions, then updating the CscArguments generator and regenerating CSharpCompilerCommand.Generated.cs through the test.

Does that match the intended design for file-based apps, or would you prefer a narrower way to pass the frozen pack versions into CSharpCompilerCommand?

[jjonescz]

Yes, the intended design is for a dotnet run file.cs to behave exactly like dotnet new console && dotnet run would. That is, the default TFM and other versions should be taken from SDK somehow.

[jjonescz]

Pushed a commit to read the relevant info from BundledVersions.props for the csc-only path of run-file.

The remaining CI failures don't seem related to run-file.

[marcpopMSFT]

Resolved the remaining NativeAOT failure in commit 61fd92e. The test was using the live BundledNETCoreAppPackageVersion (11.0 RC1) for its explicit ILCompiler and NativeAOT package items while the frozen net11 KnownILCompilerPack correctly selected preview 7. That mixed RC1 ILCompiler targets with preview 7 SDK-generated cross-target packs and caused the missing
untime.win-x64.Microsoft.DotNet.ILCompiler error. The test now reads KnownILCompilerPack.ILCompilerPackVersion and uses that version consistently for both deliberate duplicate items. The exact test now gets past the CI failure locally; this machine then stops at NativeAOT compilation because it does not have the Visual Studio ARM64 C++ tools installed.

[marcpopMSFT]

Passing checks now and test changes look reasonable to me. If this gets merged, it'll break the vmr flow as we're still working through that here: dotnet/dotnet#8542