They are very noisy and not particularly useful.

https://www.nuget.org/packages?q=runtime.

At the same time, we want to ensure that we have good transparency for users.

What to do? Should we unlist these packages or keep them as-is?

I'll give you some context. The following is from a mail I sent today (to another party) on the same topic, which led to this question.

We started shipping .NET Core in 2016. You can think of the source code (at least structurally) as having remained constant since then but that we've tried a variety of approaches to building and publishing that source as binaries. All of those approaches are on display in NuGet.org. Package managers save everything to ensure continuity for consumers. That's a good thing, but it also can create a bit of a mess if there are multiple generations of technical schemes at play.

We ship the following distributions of of the .NET platform (and related packages):

• Primary binary distribution of the .NET Runtime(s) and SDK
• Regular packages
• Special runtime packages (aka "runtime packs")

I'll briefly describe these. The primary binary distribution of the runtime and sdk is available at https://dotnet.microsoft.com/download/dotnet. This is similar to downloading node.js or OpenJDK. The only key difference is that .NET SDK includes much more in the box than the other two examples. That's not a flex, but just being objective. In fact, everything for JavaScript devs is in npm except the npm tool and node.js runtime/environment. All good.

We have regular packages. These are just like NPM or Maven packages. EntityFrameworkCore is a perfect example: https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.

You can even track that package back to source control. Check it out: https://nuget.info/packages/Microsoft.EntityFrameworkCore/7.0.0-preview.5.22302.2

That's this link: dotnet/efcore@01603c6

That means that the package was built from exactly that commit. There are ways to fake that out, but we don't do that. We ship that commit.

Note: I wish the commit in NPE was a link!

Let's get to runtime packs. This is where things get more interesting.

We had a LOT of runtime packages back when we first started. You can see a bunch of them at https://www.nuget.org/packages?q=runtime.. Most of those are abandoned now. You can see that in two ways: the last push was ages ago, and they have wonky version numbers (a lot are 4.x and we never shipped a .NET Core 4.x).

We should probably deprecate and/or unlist those packages. They are pure noise.

We do have relevant current patterns for these runtime packs. They provide the .NET implementation (in broad brushstrokes) for a given environment (like Linux x64).

https://www.nuget.org/packages?q=Microsoft.NETCoreApp.Runtime
https://www.nuget.org/packages?q=Microsoft.AspNetCore.App.Runtime

Those are the same except one is for the base runtime and the other is the web server, one layer up.

They are the same build of the product as is it at our download page, shared earlier.

The first is from: https://github.com/dotnet/runtime
The second is from: https://github.com/dotnet/aspnetcore

To make it more confusing, each of those repos builds their primary runtime deliverable, plus a bunch of associated packages.

In terms of scenarios, you download and install the product from the Microsoft download page when you want to have a globally installed product and develop or install multiple apps. We call this scenario "framework-dependent" since your app is dependent on a globally installed runtime/framework.

Some developers want to deploy the runtime with their app. We call that scenario self-contained. This is the scenario where those two categories of runtime packs are used. When you build your app, one or more of those runtime packages are downloaded and copied into your app. The local runtime on your machine is not used for that purpose (to copy into your app bin folder to make it self-contained). It's most obvious when you are on Windows x64 and wanting to build a self-contained app that will run on macOS Arm64, for example. You won't have that runtime on your machine, so it needs to be downloaded.

We also have a smaller set of runtime packs that are dependency of "regular packages".

For example, System.IO.Ports has a direct dependency on runtime.native.System.IO.Ports.

You can see this on the dependencies tab at https://www.nuget.org/packages/System.IO.Ports/7.0.0-preview.5.22301.12#dependencies-body-tab

The clue with all of these packs as being supported is a recent push or a recent version number, like 6.x or 7.x.