Support "Supplied by Platform" scenario in restore

[dsplaisted]

With .NET Core 3.0, we will be using targeting packs to deliver reference assemblies for the framework. These targeting packs will not be represented as NuGet packages in the package graph in the way that Microsoft.NETCore.App, Microsoft.AspNetCore.App, and NETStandard.Library currently are.

When a .NET Core 3 project depends on a package that has a dependency on one of these older "platform" packages, we want that platform package and its dependencies to be ignored in the NuGet graph, as those APIs are supplied by the platform via other mechanisms (targeting packs at build time and runtime packs for self-contained deployments).

We've thought of two possible ways to exclude the platform packages and dependencies from the graph. This issue is for one of them. The other one is #7343

To exclude these packages, we could pass an additional list of packages to the restore operation that should be ignored in the graph walk. We might call these "Supplied by Platform" packages. When walking the graph, if the restore operation encountered a dependency on any of these package (with a version less than or equal to the version marked as supplied by the platform), then it would ignore that dependency (and would not walk its dependencies further).

WIP spec:

• https://github.com/NuGet/Home/blob/dev-nkolev92-suppliedByPlatform/accepted/2024/supplied-by-platform.md

[nguerrera]

We can possibly represent this more generally than "supplied by platform". It is almost like a PackageReference with ExcludeAssets="All", but since we won't be taking any assets, then we shouldn't need to pick a version.

[dsplaisted]

@nguerrera I think we would want to supply a version for these packages. IE, .NET Core 3.0 might include System.Collections.Immutable 1.6.0, so we could specify that package as "Supplied by platform", but we wouldn't want to exclude a later version (ie 1.7.0) from the graph if it was encountered.

[nguerrera]

See the uptick in discussion on https://github.com/dotnet/sdk/issues/3044 and https://github.com/dotnet/core-setup/issues/6222

As we concluded in our last meeting, there's no viable workaround left for SDK on this. We deferred it based on data that suggested it would not be common. The fact that there have been more reports suggests this should be revisited.

[clairernovotny]

Bump?

[nguerrera]

@rrelyea @dsplaisted More customer pressure on https://github.com/dotnet/sdk/issues/3044. I suspect we'll see even more as 3.0 rolls out. Can we now move past the "do we need to do this?" and start talking about getting this work on the schedule and designing the feature?

[nguerrera]

https://github.com/NuGet/Home/issues/3541

[ericstj]

Bump. Just hit this again and would really like to see progress here. /cc @rrelyea

[ericstj]

Related to https://github.com/NuGet/Home/issues/8087 cc @JonDouglas

[Youssef1313]

While this is quite an old issue, I think it's more important now because of the change done in security checks to consider vulnerabilities from transitive packages, which causes false positives like https://github.com/NuGet/Home/issues/13622.

@nkolev92 Should we expect this to be fixed before .NET 9 becomes stable? Otherwise, how should we deal with false positives?

[zivkan]

Supplied by platform will not make the 9.0.100 SDK, but it is among our highest priorities, so it is getting actively worked on currently.

As per our recent blog post: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

there are a few options, such as:

• Directly reference the package
• Use CPM with transitive pinning (note this also affects package dependencies, if the project gets packed)
• use NuGetAuditSuppress