Improve pruned package data loading and handling

[dsplaisted]

Improves how package pruning data is supplied in the .NET SDK.

• Prune any later patches of a pruned package (by setting the patch value to 32767). See Should platform package pruning data represent GA of a framework or the serviced version? #44566
• Correctly supply pruned package data for .NET Framework, .NET Standard, and framework references using profiles (such as WPF and Windows Forms)
• Use pruned package data from targeting packs for .NET 10 and higher.

Targeting packs include a PackageOverrides.txt which provides the data we can use to determine the packages that should be pruned. However, this data was not entirely accurate for previous versions of .NET, as it was meant as an optimization so it didn't matter much if a few packages were missing or the versions listed weren't up to date. As of .NET 10, that should be fixed, so we will use the PackageOverrides.txt data as the source for package pruning for .NET 10 and higher.

For earlier versions of .NET, and for .NET Standard and .NET Framework, we will use data that has been calculated based on running conflict resolution and curated to be correct. This data is encapsulated in the FrameworkPackages source files.

During the .NET SDK build, targeting packs are downloaded for previous versions of .NET that are version 10.0 or higher, and the PackageOverrides.txt files from those targeting packs are laid out in a PrunePackageData folder in the SDK layout. Since there aren't currently any "previous versions of .NET that are version 10.0 or higher", this won't actually do anything until .NET 11.

The GetPackagesToPrune task will load data from the FrameworkPackages, the PrunePackageData folder, or the targeting packs for the current version of .NET that are bundled with the SDK, depending on the target framework and version.

[Copilot]

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

[ViktorHofer]

One important use-case are repositories that build shared frameworks (targeting packs) and consume them in their live build. These repositories need to be able to tell the SDK to use their live built targeting pack PackageOverrides.txt file. The current use of NetCoreTargetingPackRoot seems to make this hard. Such repos only build one targeting pack, i.e. Microsoft.NETCore.App.Ref. Therefore overriding the property wouldn't be correct as it would also impact the resolution of the pruned package data of the other non live-built targeting packs.

FWIW runtime uses this hook to tell the SDK to use the locally built packs: https://github.com/dotnet/runtime/blob/0004083b20a30dbb030aeb7e977feca0187c856c/eng/targetingpacks.targets#L119-L132

[dsplaisted]

One important use-case are repositories that build shared frameworks (targeting packs) and consume them in their live build. These repositories need to be able to tell the SDK to use their live built targeting pack PackageOverrides.txt file. The current use of NetCoreTargetingPackRoot seems to make this hard. Such repos only build one targeting pack, i.e. Microsoft.NETCore.App.Ref. Therefore overriding the property wouldn't be correct as it would also impact the resolution of the pruned package data of the other non live-built targeting packs.

FWIW runtime uses this hook to tell the SDK to use the locally built packs: https://github.com/dotnet/runtime/blob/0004083b20a30dbb030aeb7e977feca0187c856c/eng/targetingpacks.targets#L119-L132

For repositories that build shared frameworks, is it important to prune packages? Do those repos have transitive references to packages that should be pruned?

Is this problem specific to package overrides, or is it a general problem for using a repo-built targeting pack for one shared framework but also referencing another shared framework? How is that handled today?

[ViktorHofer]

For repositories that build shared frameworks, is it important to prune packages? Do those repos have transitive references to packages that should be pruned?

Yes, let me speak for runtime but this should also apply to aspnetcore and windowsdesktop. Runtime builds the live shared framework and then uses that to build the out-of-band package projects and tests. OOBs and test projects have external dependencies that bring transitives in that overlap with the framework assemblies. Those already caused CG issues in the past and it would be good to be able to use package pruning here.

Is this problem specific to package overrides, or is it a general problem for using a repo-built targeting pack for one shared framework but also referencing another shared framework? How is that handled today?

This is specific to the PackageOverrides.txt file. The SDK offers all the hooks needed to point to live built packs. I.e. the PlatformManifest.txt and other data files are used from the live built SDK.

[ericstj]

I'll add that we want our repos to use the product in the best way possible -- that way our builds test what we ship to customers. The more custom we need to make our solution the more we have to maintain and we lose valuable coverage of the SDK features.

[nkolev92]

When is this run?