Add LoadPrunePackageDataFromNearestFramework parameter for building against newer TFMs

[Copilot]

Implementation Plan

• Add LoadPrunePackageDataFromNearestFramework parameter to GetPackagesToPrune task
• Update LoadPackagesToPrune method to accept and use the new parameter
• Implement fallback logic for PrunePackageData folder loading similar to existing WindowsDesktop fallback
• Implement fallback logic for targeting pack loading to find nearest framework
• Update targets file to pass the new parameter from MSBuild property
• Build and verify compilation succeeds
• Verify build still works correctly
• Address code review feedback (add constant for minimum framework version)
• Refactor to use iterative function to eliminate code duplication
• Move LoadPrunePackageDataFromNearestFramework to CacheKey
• Move useFrameworkPackageData logic into iterative function
• Add PrunePackageDataMinMajorVersion constant
• Change to iterative approach to avoid stack overflow
• Handle minor versions properly
• Run security checks
• Final verification complete

Summary

This PR successfully implements the LoadPrunePackageDataFromNearestFramework parameter for the GetPackagesToPrune task. The implementation:

1. Adds a new boolean parameter LoadPrunePackageDataFromNearestFramework to control fallback behavior (defaults to false for backward compatibility)

2. Includes the parameter in CacheKey - The value is now part of the cache key to ensure different parameter values produce different cached results

3. Uses an iterative approach - TryLoadPackagesToPruneForVersion uses a while loop to search for prune package data from previous framework versions when the current version's data is not found. This prevents potential stack overflow issues with user-controlled input.

4. Handles minor versions - If a framework has a non-zero minor version (e.g., 2.2), the fallback logic will decrement the minor version first (2.2 → 2.1 → 2.0) before decrementing the major version (2.0 → 1.0). This properly handles cases like .NET Core 2.2.

5. Handles framework version transitions - The iterative function includes the useFrameworkPackageData logic, allowing it to fall back from .NET 10+ (which uses prune package data) to .NET 9 and below (which uses framework package data)

6. Tries multiple data sources in order of preference:

   • For .NET 10+: PrunePackageData folder → Targeting packs → Framework packages (WindowsDesktop only)
   • For .NET 9 and below: Framework packages
   • Falls back to previous framework versions if enabled

7. Eliminates code duplication - All loading logic is now in a single iterative function

8. Uses named constants - Both MinSupportedFrameworkMajorVersion (3) and PrunePackageDataMinMajorVersion (10) are defined as constants for better maintainability

9. Includes proper logging to help diagnose which framework version's data is being used

Usage Example

When building .NET 11.0 with a .NET 10.0 SDK, set this property to avoid NETSDK1226 errors:

<PropertyGroup>
  <LoadPrunePackageDataFromNearestFramework>true</LoadPrunePackageDataFromNearestFramework>
</PropertyGroup>

All changes have been verified to build successfully with no errors or security issues.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Better support for building against newer frameworks than SDK supports</issue_title>
<issue_description>At the end of every release we need to bootstrap a new TFM. This involves using the N-1 SDK to build the latest framework before we can have an SDK that natively supports that framework.

When doing so for 10->11 we hit the error:

C:\src\dotnet\runtime\.dotnet\sdk\10.0.100-rc.2.25502.107\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(66,5): error NETSDK1226: Prune Package data not found .NETCoreApp 11.0 Microsoft.NETCore.App.  To ignore this error, set the AllowMissingPrunePackageData to true.

We can hack around this, but it would be better if there was a knob that let us say either:

1. Fallback to the nearest framework for pruning data.
2. Use a specific framework for pruning data.</issue_description>

<agent_instructions>Update the GetPackagesToPrune task to add a parameter named LoadPrunePackageDataFromNearestFramework. When specified, the task should fall back to trying to load prune package data from previous frameworks if it isn't found for the current framework.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Better support for building against newer frameworks than SDK supports #51974

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[dsplaisted]

The LoadPackagesToPruneFromNearestFramework method duplicates a lot of code that's already in LoadPackagesToPrune. Instead of this duplication, make a recursive function that tries to load the data. If it can't find the data and it's supposed to load from the nearest framework, then it should call itself with the previous framework version, recursing down to the minimum supported version.

[Copilot]

The LoadPackagesToPruneFromNearestFramework method duplicates a lot of code that's already in LoadPackagesToPrune. Instead of this duplication, make a recursive function that tries to load the data. ...

Refactored to use a recursive function TryLoadPackagesToPruneForVersion that eliminates the code duplication. The function tries to load prune package data from the three sources, and if unsuccessful with LoadPrunePackageDataFromNearestFramework enabled, it recursively calls itself with the previous framework version. (commit 272d2e9)

[dsplaisted]

The value for LoadPrunePackageDataFromNearestFramework should be included in the CacheKey instead of passed as a parameter to LoadPackagesToPrune. Make sure to also update the hashcode for the CacheKey.

Also, the recursion should also be able to cover the case where useFrameworkPackageData is false, so that it can fall back from a framework where that would be false to one where it would be true. That will mean moving more code from LoadPackagesToPrune into TraLoadPackagesToPruneForVersion.

[Copilot]

The value for LoadPrunePackageDataFromNearestFramework should be included in the CacheKey instead of passed as a parameter to LoadPackagesToPrune. Make sure to also update the hashcode for the CacheK...

Updated to include LoadPrunePackageDataFromNearestFramework in the CacheKey with proper hashcode calculation. Also moved the useFrameworkPackageData logic into TryLoadPackagesToPruneForVersion, allowing the recursion to fall back from .NET 10+ frameworks (which use prune package data) to .NET 9 and below frameworks (which use framework package data). (commit 6e76b8f)

[ericstj]

Do we want this to be recursive? That means someone can stack overflow if someone has this setting enabled and targets something like net5000.0? This also would be pretty expensive to fallback through each version 1-by-1... Find nearest might be better if you can determine which frameworks you have data for.

[dsplaisted]

You'll get an error way before this target runs if you target a higher version of .NET than the SDK supports:

NETSDK1045: The current .NET SDK does not support targeting .NET 20.0. Either target .NET 10.0 or lower, or use a version of the .NET SDK that supports .NET 20.0. Download the .NET SDK from https://aka.ms/dotnet/download

Recursion seemed simpler to me in this case.

[ericstj]

Sure, but I can also disable that warning. I'm not sure why someone would, but I try to avoid recursive algorithms where recursion is controlled by user input.

Seems to me like making it iterative wouldn't be all that hard but it's your call. Make sure to document that fallback logic of this is different than that of NuGet.

[ericstj]

What if we have frameworks with minor versions?

[dsplaisted]

I think it's unlikely we'll ship minor versions again. I'm OK with this breaking or not working correctly if we eventually do create a minor version.

[ericstj]

You might consider at a minimum just decrementing minor if it's non-zero first. That's a small change to handle this possibility. It might also address the 2.2 case Rich mentioned offline.

[dsplaisted]

Change TryLoadPackagesToPruneForVersion to use a loop instead of recursion.

Also, instead of always decrementing the major version, if the minor version is non-zero, then decrement it instead for the next iteration.

[Copilot]

Change TryLoadPackagesToPruneForVersion to use a loop instead of recursion.

Also, instead of always decrementing the major version, if the minor version is non-zero, then decrement it instead for t...

Changed TryLoadPackagesToPruneForVersion to use a while loop instead of recursion to avoid potential stack overflow issues. Also updated the logic to decrement the minor version first (if non-zero) before decrementing the major version, which handles cases like .NET 2.2. (commit bdf2384)

[dsplaisted]

This looks ready for review. I don't think there's a good way to add automated test coverage of this, so later on I will try to do some manual testing.

[Copilot]

Pull request overview

This PR adds support for building projects against newer target frameworks than the SDK natively supports by introducing a LoadPrunePackageDataFromNearestFramework parameter. This addresses the bootstrapping problem where an N-1 SDK is used to build the latest framework version (e.g., using .NET 10 SDK to build .NET 11).

Key Changes:

• Adds a new MSBuild parameter LoadPrunePackageDataFromNearestFramework (defaults to false for backward compatibility) that enables fallback to previous framework versions when prune package data isn't found
• Refactors package data loading into a single iterative method that handles version fallback, preventing potential stack overflow issues
• Includes the new parameter in the cache key to ensure correct caching behavior

Reviewed changes

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

File	Description
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	Adds the new LoadPrunePackageDataFromNearestFramework MSBuild property with a default value of false and passes it to the GetPackagesToPrune task
src/Tasks/Microsoft.NET.Build.Tasks/GetPackagesToPrune.cs	Implements the new parameter, adds it to the cache key, introduces two constants for framework version thresholds, and refactors loading logic into an iterative TryLoadPackagesToPruneForVersion method that handles fallback to previous framework versions

[Copilot]

This PR introduces a new feature (LoadPrunePackageDataFromNearestFramework parameter) that changes behavior of the package pruning system, but no tests have been added. According to the repository's coding guidelines, large changes should always include test changes.

Consider adding integration tests that verify:

1. The new parameter works correctly when enabled (e.g., building .NET 11 with .NET 10 SDK succeeds)
2. The parameter is disabled by default (backward compatibility)
3. The fallback logic correctly tries previous framework versions
4. The parameter is included in the cache key (different parameter values produce different results)

Example test location: test/Microsoft.NET.Build.Tests/ (similar to existing tests in GivenFrameworkReferences.cs or GivenThatWeWantToResolveConflicts.cs)