.NET Package Maintenance (deprecation)

[leecow]

.NET Package Maintenance

.NET Core was released in June 2016, and over the last six years, many thousands of NuGet packages have been published under the .NET umbrella. Many of these packages are legacy or out-of-support already. As things stand today, there is no information associated with these packages to indicate their support status.

To provide developers with better package support status information, the .NET team will start using the NuGet Package Deprecation feature. Deprecated packages remain visible on nuget.org, to clients such as Visual Studio and the .NET CLI, and can be restored by projects. In addition to updating existing packages, we will mark packages as appropriate when new versions are released so that developers can access up-to-date information on the packages they use.

Which Packages will be deprecated

As a general principle, packages that are out of support per the .NET Support Policy will be marked deprecated. Packages that were part of abandoned projects, such as dnx, will be marked deprecated, as will packages that were part of earlier preview releases.

After we are caught up marking previously released packages, we will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage. We will work out how best to address these packages getting caught up and staying current at each release.

Timing

We would like to begin the package marking process next week and first want to hear if there are any issues that have not been considered. Please see the .NET Package Deprecation list and use this issue to comment.

[SeanKilleen]

I appreciate the heads up on this.

My only concern -- In my mind, when I think of deprecation, I think:

• The package is no longer supported/maintained and users should upgrade for the health of their application (in line with the first use cases you mention)
• Something is an issue in a package and folks should update ASAP. Major bug, vulnerability, etc.
• An unintended or bad publish, which likely falls into "major bug" territory above where users would be advised not to use that package.

However,

We will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

Seems like it could risk creating a noise issue in the ecosystem. There isn't anything wrong with the package in that instance; we're just trying to encourage users to stay current. And while I think encouraging to stay current is a good goal, I think deprecating all prior packages beyond current seems a bit heavy-handed to get there, and may risk users treating deprecation as less concerning or worthy of their investigation, harming the overall goal.

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

[KalleOlaviNiemitalo]

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage.

Do you mean AspNetCore 2.1? That's what is supported on .NET Framework. https://dotnet.microsoft.com/platform/support/policy/aspnetcore-2.1

[terrajobst]

@SeanKilleen

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

I like that. I have seen folks running "update all" in VS's UI just in case. Some folks even forget to uncheck "include prerelease" which then creates more problems down the road.

Maybe NuGet should have safe update all, i.e. update to latest stable minor version? /cc @JonDouglas @clairernovotny

$ dotnet refresh

or

$ dotnet restore --refresh

Basically "update package references to latest stable minor (if the package reference is a stable version) or latest minor prerelease (if the package reference is a prerelease).

[SeanKilleen]

@terrajobst yes, I think something like that would lead to more impact.

If the goal is ".NET projects keep their dependencies up to date", I think tooling like the above -- as well as great release notes and upgrade guidance -- will better enable it without the negative impact of diluting the meaning of a deprecation.

[schemburkar]

Can the packages be marked outdated rather than deprecated?

The subtle difference being that it tells consumers that the package is still fine, just not latest vs it might have known vulnerabilities and is now deprecated

I do agree with @SeanKilleen that there might be noise in the ecosystem when this happens.

[leecow]

Thanks, @KalleOlaviNiemitalo. What I'm referring to with AspNetCore 2.2 is that a number of new features were added which are not in 2.1 creating a support culdesac. Some AspNetCore / .NET Framework customers depend on these features so we need to be thoughtful in how we handle that set of 2.2 packages.

[leecow]

@schemburkar - I understand the distinction you're pointing out. We want to use the NuGet feature so that the marking is leveraged by appropriate tools (VS, etc) as seamlessly as possible. I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

[schemburkar]

I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

I thought it was but I could be wrong

Additional point is that would there be a ingestion period from the day newer version arrives and the older version is marked?
Coz I'm thinking of extensions and library authors talking some time till they consume the latest version and update pinned dependencies

[SeanKilleen]

@schemburkar

Can the packages be marked outdated rather than deprecated?

Doesn't this happen by virtue of a new package being created? Nuget automatically finds that there's a new package available. What purpose would such a label serve in that case? (just curious.) At that point it seems like it's a solved problem?

[schemburkar]

@SeanKilleen agreed. I was looking at it from the angle of project maintenance perspective where you would now see a ton of packages that are marked deprecated and some of them due to vulnerablities vs some just being stale.

@leecow I was looking into the nuget announcement of the deprecated feature and it turns out the package can post a message why it's deprecated. So if all the packages that will be deprecated have a clear message it would help

[JonDouglas]

Hi friends,

We have three words we use over at NuGet. TL;DR:

• Deprecated - Please don't use this for a disclosed reason and please use this suggested alternative(if any).
• Vulnerable(NEW) - Please don't use this due to disclosed/known vulnerability and update/replace/remove/do nothing accordingly.
• Outdated - Please consider using a newer version.

Similar to Immo's idea, we would like to work on NuGet/Home#4103 (comment) but it will need time for a thoughtful design to account for cases like this.

Go 👍 and comment! NuGet/Home#4103 though if you're interested in that experience.

Additionally for the all-up experience, we're trying to provide warnings/errors for each of these three words. Right now it's proposed as dotnet audit:

Go 👍 and comment! NuGet/Home#11549

Hope this helps.

[SeanKilleen]

Based on @JonDouglas's comment above (thanks Jon!), it would seem that:

We will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

...would not be considered the correct approach. The packages will naturally be considered outdated, and so to mark them as deprecated with a message in this instance would be a sort of duplicate meaning that unintentionally overloads the concept of package deprecation.

Given that, I'd suggest holding off on that particular aspect for now, and focusing that effort elsewhere. (I still agree with deprecating unsupported/unmaintained packages as I think that's a clear indicator that a change needs to be considered on the consumer side.)

[teo-tsirpanis]

First of all that's great news, thanks for taking action on this. I have some feedback:

• This list is huge (with 2535 packages) and has lots of actively maintained ones in between. It would be helpful to somehow mark (with emojis for example to allow easily Ctrl+Fing) which of these packages are entirely deprecated and will not receive new versions, and which have all but their latest version deprecated and will get patched if needs be.
  • Likely off topic, but why is System.Runtime.Intrinsics.Experimental in the list of still-supported ASP.NET Core 2.1 packages? This package provides experimental hardware intrinsics APIs for .NET Core prior to 3.0, and ASP.NET Core 2.1 is supported only on .NET Framework. The .NET Core 2.1 versions are even unlisted which is a rare occurence. It was probably included by mistake; I don't know how easy it is to theoretically "break a support promise" and remove it from the list.
• Yeah, ASP.NET Core 2.2 is a sad story. Users would click "Update All" and go from the supported 2.1 to the unsupported 2.2. NuGet could remedy it by updating to the latest non-deprecated version.
• My understanding is that there are some packages that while still supported for .NET Framework and .NET Standard 2.0, have no reason to be used for newer frameworks because they were moved to inbox, and therefore are no more regularly updated. Examples are System.Memory and System.Threading.Tasks.Extensions, providing spans and value tasks respectively. Will there be some guidance about removing them? The SDK could even special-case them and warn if they are used on a framework that does not need them.
  • A subcategory of these packages are some formerly OOB ones that got merged into the shared framework and stopped being updated. An example is Microsoft.Win32.Registry. Deprecating only the .NET 5 versions but not the .NET Core 3.1 might cause the same headaches with ASP.NET Core 2.2, but thankfully these could be deprecated in their entirety once all their frameworks go out of support.

[huoyaoyuan]

I think we should do this step by step.

• Packages that are parts of deprecated or earlier experimental application models should be deprecated first, for example dnx.
• OOB packages to provide language features on older TFMs should not be deprecated. There could be a message when using them on newer frameworks, but do not warn for existing projects on older framework.
• Packages that were mainly used as a dependency and replaced now can be deprecated, for example Libuv.
• Do not deprecate the final available version on a target framework unless the framework is totally deprecated.

[Tragetaschen]

I would like to discuss the deprecation of the the Microsoft.AspNetCore.Components.DataAnnotations.Validation package. It's really an odd one out as it was never actually released during the 3.2 time frame and remains as an rc1 version on NuGet.

It's my understanding that there was an attempt to solve the problem within the framework (dotnet/runtime#31400), but it was decided to continue providing this within the Blazor context. This effort does not seem to result in a package in the .NET 7 timeframe (dotnet/aspnetcore#28640)

For the time being, the documentation calls out to continue using the prerelease package normally, so I propose to remove the deprecation label.

[guardrex]

Let me second that remark/question by @Tragetaschen. It is still in the Blazor docs, and I was just asked on the docs repo about the depreciation move. It's marked for .NET 8 now, so don't we want to keep it viable for use as "experimental" at this time, not depreciated/legacy? cc: @mkArtakMSFT

[mkArtakMSFT]

I would like to discuss the deprecation of the the Microsoft.AspNetCore.Components.DataAnnotations.Validation package. It's really an odd one out as it was never actually released during the 3.2 time frame and remains as an rc1 version on NuGet.

Thanks for bringing this up, @Tragetaschen. That one wasn't intended to be deprecated. I've fixed it on NuGet already. Hopefully, we'll get to review the issue that you've pointed out in .NET 8 timeframe and decide how we will move forward with this package.

Thanks for bringing this to my attention, @guardrex!

[HolidayLighting]

So if a package is depricated like Microsoft.AspNetCore.SignalR.Core how do we know what its replacement is?

[mkArtakMSFT]

So if a package is depricated like Microsoft.AspNetCore.SignalR.Core how do we know what its replacement is?

Some packages don't have a replacement. Some have been moved to be part of the framework, so there is no separate package being published to NuGet. The best way to find out how to move forward for a specific package is to look up the documentation for corresponding APIs in our docs. For SignalR specifically, take a look at https://docs.microsoft.com/en-us/aspnet/core/signalr/introduction and switch the framework version to match the version that your project is targeting:

The documentation will guide you how to get access to the appropriate APIs, including referencing the packages that may be required.

[KalleOlaviNiemitalo]

For ASP.NET Core 2.1 on .NET Framework, are Microsoft.AspNetCore.SignalR 1.0.4 and Microsoft.AspNetCore.SignalR.Core 1.0.15 the supported versions? Versions 1.0.* have not been marked as deprecated at nuget.org, although version 1.1.0 has.

[BrennanConroy]

are Microsoft.AspNetCore.SignalR 1.0.4 and Microsoft.AspNetCore.SignalR.Core 1.0.15 the supported versions?

Yes, they were released as part of ASP.NET Core 2.1 and have the same EOL

[CoolDadTx]

I'm confused about System.ComponentModel.Annotations being deprecated. That is where the core data annotations like Required are at. The latest released package is marked deprecated but the pre-release 6.0 version is not released yet. Some companies, like ours, do not allow the use of pre-release packages. Furthermore the official docs for things like Required point to that assembly. If I remove that dependency from my project then it won't compile anymore. This seems like a catch-22. If your company policies requires that you keep all packages up to date for security reasons AND you are not allowed to rely on pre-release packages because of stability then there is no way to correctly compile your code anymore.

Bear in mind here that we are using TFMs here (.NET 4.7.2 and .NET 6.0). NF comes with these attributes built into the framework so we could add a conditional reference to that assembly. .NET 6 should be using the package (that is now deprecated). But historically in this situation you just reference the package for both frameworks and let the compiler deal with it. This would no longer work.

I would strongly recommend a policy around deprecating packages to avoid this situation. If a package is being deprecated in lieu of a newer package then the deprecation should not occur until the newer package is released (not pre-release). If a package is obsolete then provide clear documentation on what the replacement is. I've looked for the "replacement" for the annotations package and other than the pre-release version I see none.

[KalleOlaviNiemitalo]

Comparing https://web.archive.org/web/20221201093821/https://dotnet.microsoft.com/en-us/platform/support/policy/aspnetcore-2.1 to https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages and https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/external-packages, I see the following have been removed from the list of supported packages:

• Microsoft.AspNetCore.DataProtection.Redis.0.4.0.nupkg
• Microsoft.AspNet.Mvc.FixedDisplayModes.5.2.7-preview1.nupkg
• Microsoft.AspNet.Mvc.Mvc4Views.CSharp.5.2.7-preview1.nupkg
• Microsoft.AspNet.Mvc.Mvc4Views.VisualBasic.5.2.7-preview1.nupkg

Of these, the MVC packages are listed in the .NET Package Deprecation list, but Microsoft.AspNetCore.DataProtection.Redis is not.

Although I did not use Microsoft.AspNetCore.DataProtection.Redis, this makes me feel uneasy about the other aspnetcore-2.1 packages. Can I somehow subscribe to updates of the lists, in order to know when the "minimum of 12 months notification prior to the end of support" starts ticking? Will packages be marked as deprecated in NuGet Gallery when the notification period starts, or only when support ends?

By the way, these versions in https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages look wrong:

Package name	Version
Microsoft.Diagnostics.Tracing.EventSource.	edist
Microsoft.DotNet.PlatformAbstra	tions

[jaredtait]

We are referencing Microsoft.AspNetCore.Server.IIS

That package was only ever supported for netcoreapp2.2 which has been out of support for years. The migration guidance if you still want to run on netfx 4.8 would be to use the Microsoft.AspNetCore.Server.IISIntegration package which is still supported.

Where did the GetIISServerVariable(string) (or GetServerVariable(string) extension method land? It does not seem to be in Microsoft.AspNetCore.Server.IISIntegration

See https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages

This only states that the latest is supported with no timeframes for future support. Makes me think it could go at any time.

Thanks @BrennanConroy and @cremor for helping!

[cremor]

This only states that the latest is supported with no timeframes for future support. Makes me think it could go at any time.

One level above that page you will find this one: https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet
That states the following:

To help facilitate migrating applications to ASP.NET Core on .NET Core, the specified ASP.NET Core 2.1 packages (latest patched version only) will be supported on the .NET Framework and follow the support cycle for those .NET Framework versions. ASP.NET Core 2.1 is defined as "Tools" in the Microsoft Support Lifecycle Policy. A "Tool" requires a minimum of 12 months notification prior to the end of support. For more information, see this KB Article.

[soenneker]

This approach is causing confusion, and you're going to have many here shortly who will be asking for guidance.

You need to have replacements ready to go if you're going to deprecate. Otherwise why deprecate? The 'last updated date' is enough of an indicator that something isn't being updated. I don't like using libraries that are deprecated, but there are no other alternatives.

What we need is the ability to see where types are going after deprecation. I need to be able to pick up the new package from NuGet's package recommendation and use it right out of the box with minimal changes. Instead I'm searching MS docs, I'm seeing packages that are marked 'internal only', and after 10 minutes it's clear they don't have a replacement.

The definition of 'deprecation': "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative."

I understand libraries need to be deprecated, and there's a need to rewrite and organize. I don't understand why you would deprecate a huge chunk of your libraries without having their replacements (and documentation) ready... I think this is a blunder by the .NET team, and again I think many here will be asking soon 'so where do I go to get X type'.

[China-Mr-zhong]

This approach is causing confusion, and you're going to have many here shortly who will be asking for guidance.

You need to have replacements ready to go if you're going to deprecate. Otherwise why deprecate? The 'last updated date' is enough of an indicator that something isn't being updated. I don't like using libraries that are deprecated, but there are no other alternatives.

What we need is the ability to see where types are going after deprecation. I need to be able to pick up the new package from NuGet's package recommendation and use it right out of the box with minimal changes. Instead I'm searching MS docs, I'm seeing packages that are marked 'internal only', and after 10 minutes it's clear they don't have a replacement.

The definition of 'deprecation': "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative."

I understand libraries need to be deprecated, and there's a need to rewrite and organize. I don't understand why you would deprecate a huge chunk of your libraries without having their replacements (and documentation) ready... I think this is a blunder by the .NET team, and again I think many here will be asking soon 'so where do I go to get X type'.

I'm also confused right now, being marked as deprecated but can't find a replacement package

[China-Mr-zhong]

您可以在面向3.1+的库中添加框架参考(注意:6.0+是目前唯一受支持的版本) https://learn . Microsoft . com/aspnet/core/fundamentals/target-aspnetcore？view = aspnet core-7.0 & tabs = visual-studio # use-the-aspnet-core-shared-framework

This method works, but fortunately my current projects are all NET6

[ChristopherVR]

This seems extremely confusing now.

What should Microsoft.AspNetCore.Http.Features be replaced with? I can't seem to find the replacement. If there is no replacement, how does it make sense to deprecate the package until there is a replacement available?

[cremor]

@ChristopherVR See Use the ASP.NET Core shared framework

This is also visible on the documentation page of the types. E.g. on the ISessionFeature Interface page you can see the note "Package: Microsoft.AspNetCore.App.Ref".

@leecow Maybe include the link Use the ASP.NET Core shared framework in the initial post of this issue (and in the anncouncement itself)?

[codelovercc]

I want to use model binding attributes in namespace Microsoft.AspNet.Mvc.ModelBinding in my class library project(etc: BindNeverAttribute BindRequiredAttribute ..) , but I don't want to reference the entire Microsoft.AspNetCore.App libraries in my class library project. What can I do?

[louiecampagna-okta]

What would be the replacement for Microsoft.AspNetCore.Authentication.Cookies ?

[cremor]

@louiecampagna See my comment which is just 2 comments above yours.

[damiensawyer]

but I don't want to reference the entire Microsoft.AspNetCore.App libraries in my class library project. What can I do?

Well @codelovercc, it appears that Microsoft.AspNetCore.App is also now deprecated (which is what brought me here)... so there's no joy there either.

I agree with @soenneker that this decision is fraught with issues. Why deprecate something without a replacement lined up and easily locatable (ideally as part of the message signalling the depracation)? Are we to take the opinon that those deprecated and not replaced features are 'gone' and we should avoid them? From an optics point of view, this is sending a very negative message. One might be led to believe that dotnet is 'ramping down' rather than growing.

[cremor]

@damiensawyer The Microsoft.AspNetCore.App NuGet Package is deprecated because that package was never released for any version after ASP.NET Core 2.2.
Since ASP.NET Core 3.0 the Microsoft.AspNetCore.App shared framework is used instead and that is not deprecated. Just use <FrameworkReference> instead of <PackageReference>. See Use the ASP.NET Core shared framework.

@leecow I repeat my request to include that information in the first post of this issue.

[damiensawyer]

Thanks @cremor - that's really useful! I'd never before gone down the rabit whole of Framework References. It all makes sense now. Thanks.

[codelovercc]

Hi, @damiensawyer , use the ASP.NET Core shared framework will work, but it will reference the entire Microsoft.AspNetCore.App libraries right? I want keep my library project small and simple, so I don't prefer this way.

[huoyaoyuan]

I want keep my library project small and simple

For developers, the ASP.NET shared package is installed with dotnet SDK, so there's no issue about size.

For end users and deployment, this would require trimming unused ASP.NET components, at least at assembly level. Trimming isn't enabled in default config and is still incompatible with some key scenarios like WPF. I can see this scenarios become annoying.

[cremor]

For end users and deployment, this would require trimming unused ASP.NET components, at least at assembly level.

If your library needs to reference something from the ASP.NET Core framework this means you are providing a library for ASP.NET Core applications. Your end users would need the ASP.NET Core runtime (which includes the framework) anyway in this situation. There is no difference in deployment size caused by your library referencing the ASP.NET Core framework.

And if your end users do not need the ASP.NET Core runtime (so they either use the .NET Windows Desktop runtime or just the base .NET runtime for console apps) then they also shouldn't have to reference a library which includes ASP.NET Core stuff, regardless if that library references the ASP.NET Core framework or just NuGet packages. Meaning: If your library has users outside of ASP.NET Core runtimes, you should offer a seperate base library without the ASP.NET Core specific code.

[huoyaoyuan]

And if your end users do not need the ASP.NET Core runtime (so they either use the .NET Windows Desktop runtime or just the base .NET runtime for console apps) then they also shouldn't have to reference a library which includes ASP.NET Core stuff

I had met the case that I tried to build some HTTP server functionalities in desktop application. The whole ASP.NET framework is overkill for such scenario.

[noqcks]

I've noticed that there are packages in the deprecated package list that are not deprecated in NuGet.

Just one example: https://www.nuget.org/packages/Microsoft.AspNet.SignalR.ServiceBus3

Im wondering if there's a specific reason for this? Presumably if it's on the deprecated list, it should also be deprecated on NuGet?

[marius-haugan]

I'm curiously wondering how/why the Microsoft.AspNetCore.Http.Extensions 2.2.0 version is deprecated, while the 2.1.21 package is not?

[KalleOlaviNiemitalo]

@marius-haugan, Microsoft.AspNetCore.Http.Extensions is one of the ASP.NET Core 2.1 Supported Packages that remain for .NET Framework compatibility. ASP.NET Core 2.2 was not an LTS release.

[KalleOlaviNiemitalo]

By the way, these versions in https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages look wrong:

Package name	Version
Microsoft.Diagnostics.Tracing.EventSource.	edist
Microsoft.DotNet.PlatformAbstra	tions

Those were corrected some time between 2023-05-21 and 2024-01-03, possibly in the 2023-11-22 update. Additionally, "Microsoft.VisualBasic. 0.3.x" was replaced with "Microsoft.VisualBasic 10.3.x". I did not find any other content changes between these versions of the web page.

[wehnertb]

Deprecating a package without any explanation as to how to work around the loss is a headache to say the least. Microsoft.AspNetCore.Authentication is now deprecated and no explanation on how we're supposed to move forward.

If a package was moved to be part of Core, it should be stated in the NuGet repo that a) it was moved and b) here's the new reference. Or something, now we're just in the dark hoping we can figure out what the heck to do from this point on.

[ItWorksOnMyMachine]

There are no non-deprecated versions of Microsoft.Bcl. However, Microsoft.Net.Http, the latest version, which is not deprecated, has a dependency on Microsoft.Bcl. How do you recommend we handle this?

[julealgon]

@ItWorksOnMyMachine

There are no non-deprecated versions of Microsoft.Bcl. However, Microsoft.Net.Http, the latest version, which is not deprecated, has a dependency on Microsoft.Bcl. How do you recommend we handle this?

Apparently that package should also be marked as deprecated?

This package is not supported in Visual Studio 2010, and is only required for projects targeting .NET Framework 4.5, Windows 8, or Windows Phone 8.1 when consuming a library that uses this package.

Supported Platforms:

• .NET Framework 4
• Windows 8
• Windows Phone 8.1
• Windows Phone Silverlight 7.5
• Silverlight 4
• Portable Class Libraries

https://www.nuget.org/packages/Microsoft.Net.Http#readme-body-tab

[kevincathcart-cas]

For some reason Microsoft.NETCore.Jit is not marked as deprecated, despite having no nuget.org releases since 2.0, and being listed in the .NET Package Deprecation list.

[JaredShaver]

What is the replacement for Microsoft.AspNetCore.DataProtection.SystemWeb? The current documentation is directing users to use this deprecated package. dotnet/AspNetCore.Docs#33149

[KalleOlaviNiemitalo]

I looked again at the ASP.NET Core 2.1 Supported Packages list, because of dotnet/aspnetcore#58598. The list was apparently modified some time between 2024-03-26 and 2024-05-22, removing these packages:

Package name	Version
Microsoft.AspNetCore.DataProtection.AzureKeyVault	2.1.x
Microsoft.AspNetCore.DataProtection.AzureStorage	2.1.x
Microsoft.CSharp	4.5.x
Microsoft.Diagnostics.Tracing.EventSource.Redist	2.1.x
Microsoft.Extensions.Caching.Abstractions	2.1.x
Microsoft.Extensions.Caching.Memory	2.1.x
Microsoft.Extensions.Caching.SqlServer	2.1.x
Microsoft.Extensions.Configuration	2.1.x
Microsoft.Extensions.Configuration.Abstractions	2.1.x
Microsoft.Extensions.Configuration.AzureKeyVault	2.1.x
Microsoft.Extensions.Configuration.Binder	2.1.x
Microsoft.Extensions.Configuration.CommandLine	2.1.x
Microsoft.Extensions.Configuration.EnvironmentVariables	2.1.x
Microsoft.Extensions.Configuration.FileExtensions	2.1.x
Microsoft.Extensions.Configuration.Ini	2.1.x
Microsoft.Extensions.Configuration.Json	2.1.x
Microsoft.Extensions.Configuration.KeyPerFile	2.1.x
Microsoft.Extensions.Configuration.UserSecrets	2.1.x
Microsoft.Extensions.Configuration.Xml	2.1.x
Microsoft.Extensions.DependencyInjection	2.1.x
Microsoft.Extensions.DependencyInjection.Abstractions	2.1.x
Microsoft.Extensions.DependencyInjection.Specification.Tests	2.1.x
Microsoft.Extensions.DependencyModel	2.1.x
Microsoft.Extensions.FileProviders.Abstractions	2.1.x
Microsoft.Extensions.FileProviders.Composite	2.1.x
Microsoft.Extensions.FileProviders.Embedded	2.1.x
Microsoft.Extensions.FileProviders.Physical	2.1.x
Microsoft.Extensions.FileSystemGlobbing	2.1.x
Microsoft.Extensions.Hosting	2.1.x
Microsoft.Extensions.Hosting.Abstractions	2.1.x
Microsoft.Extensions.Http	2.1.x
Microsoft.Extensions.Http.Polly	2.1.x
Microsoft.Extensions.Identity.Core	2.1.x
Microsoft.Extensions.Identity.Stores	2.1.x
Microsoft.Extensions.Localization	2.1.x
Microsoft.Extensions.Localization.Abstractions	2.1.x
Microsoft.Extensions.Logging	2.1.x
Microsoft.Extensions.Logging.Abstractions	2.1.x
Microsoft.Extensions.Logging.AzureAppServices	2.1.x
Microsoft.Extensions.Logging.Configuration	2.1.x
Microsoft.Extensions.Logging.Console	2.1.x
Microsoft.Extensions.Logging.Debug	2.1.x
Microsoft.Extensions.Logging.EventLog	2.1.x
Microsoft.Extensions.Logging.EventSource	2.1.x
Microsoft.Extensions.Logging.TraceSource	2.1.x
Microsoft.Extensions.ObjectPool	2.1.x
Microsoft.Extensions.Options	2.1.x
Microsoft.Extensions.Options.ConfigurationExtensions	2.1.x
Microsoft.Extensions.Primitives	2.1.x
Microsoft.Extensions.WebEncoders	2.1.x
Microsoft.NETCore.Platforms	2.1.x
Microsoft.NETCore.Targets	2.1.x
Microsoft.VisualBasic	10.3.x
Microsoft.Windows.Compatibility	2.0.x
Microsoft.Windows.Compatibility.Shims	2.0.x
Microsoft.XmlSerializer.Generator	2.0.x
Runtime.native.System.Data.SqlClient.sni	4.5.x
System.Buffers	4.5.x
System.Collections.Immutable	1.5.x
System.ComponentModel.Annotations	4.5.x
System.ComponentModel.Composition	4.5.x
System.Composition	1.2.x
System.Composition.AttributedModel	1.2.x
System.Composition.Convention	1.2.x
System.Composition.Hosting	1.2.x
System.Composition.Runtime	1.2.x
System.Composition.TypedParts	1.2.x
System.Diagnostics.DiagnosticSource	4.5.x
System.IO.Pipelines	4.5.x
System.Json	4.5.x
System.Memory	4.5.x
System.Net.Http.WinHttpHandler	4.5.x
System.Net.WebSockets.WebSocketProtocol	4.5.x
System.Numerics.Vectors	4.5.x
System.Reflection.DispatchProxy	4.5.x
System.Reflection.Metadata	1.6.x
System.Reflection.TypeExtensions	4.5.x
System.Runtime.CompilerServices.Unsafe	4.5.x
System.Security.Cryptography.OpenSsl	4.5.x
System.Text.Encodings.Web	4.5.x
System.Threading.Channels	4.5.x
System.Threading.Tasks.Dataflow	4.9.x
System.Threading.Tasks.Extensions	4.5.x
System.ValueTuple	4.5.x

I suppose most of those are covered by the principle in .NET Package Maintenance (deprecation) File List:

Where a given package has a current version that is in support, the previous versions will be marked deprecated.

However, I checked a few of those packages at NuGet.org and they have not been marked as deprecated there. For example, https://www.nuget.org/packages/Microsoft.Extensions.Configuration.Binder/2.1.10 does not show that version as deprecated. So, it's not clear to me whether this constitutes a "minimum of 12 months notification prior to the end of support" as stipulated in ASP.NET Support Policy.

I suppose applications are now expected to use 8.0.* versions of Microsoft.Extensions.* packages instead, but this is a breaking change; these new versions are somewhat incompatible with Visual Studio 2017. These incompatibilities can be worked around but it's somewhat cumbersome:

• MSBuild files have been moved from the build directory to buildTransitive, which the old version of NuGet does not recognize.
• Some packages include source generators that the old version of Roslyn cannot load as analyzers, causing warnings. Although the packages contain MSBuild files that attempt to exclude incompatible or unnecessary analyzers, this doesn't work because of buildTransitive.
• MSBuild files in some packages use the [MSBuild]::IsTargetFrameworkCompatible intrinsic function, which requires MSBuild 16.7 or higher.