Skip to content

Trim earlier versions of platform packages from NuGet graph #9807

Closed

Description

@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:

Use empty platform packages

One option is for us to produce empty 3.0 versions of these platform packages, and implicitly reference them from .NET Core 3.0 projects. This would prevent the previous versions of the packages, as well as their dependencies, from being used in the graph.

However, these empty 3.0 packages would be confusing to see in the list of installed packages in the package manager UI. So if we go with the "empty package" option, we'd like a way to entirely exclude these packages from the NuGet UI.

This option also has the downside that it requires us to ship these empty packages in the NuGetFallbackFolder in the SDK, which we'd like to get rid of.

Pass "supplied by platform" packages to NuGet

This would involve a feature in NuGet: NuGet/Home#7344

We would pass the list of platform packages that should be ignored to the restore operation, and it would ignore those packages if it encountered them in the graph walk.

Activity

  1. transferred this issue fromdotnet/clion Jan 31, 2020
  2. added this to the 3.0.1xx milestone on Jan 31, 2020
  3. modified the milestones: 3.0.1xx, Backlog on Oct 26, 2021
  4. baronfel commented on Jul 23, 2025

    @baronfel
    Member

    hey @marcpopMSFT / @aortiz-msft - I think pruning and supplied by platform might cover this, no? Can we close our side now?

  5. marcpopMSFT commented on Jul 23, 2025

    @marcpopMSFT
    Member

    Seems right to me. Let's close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions