Repository navigation
.NET Package Deprecation #10347
Description
.NET Package Deprecation
We will start using the NuGet Package Deprecation feature to mark .NET packages that are out of support per the .NET Support Policy. Accurate and timely deprecation markings will enable Visual Studio, the .NET CLI, and nuget.org to indicate which packages are out of support, have been deprecated, or have been superseded.
What's being done
We are applying deprecation markings across .NET packages on NuGet, starting with the backlog of versions that are already out of support.
The following principles apply:
- Previous versions of actively maintained packages will be marked deprecated when they go out of support.
- When a package version is replaced by a security fix, the previous version will be marked deprecated to direct users to the patched version.
- Deprecated packages remain visible on nuget.org, in Visual Studio, and in the .NET CLI. They can still be restored by projects. This is an informational marking, not a removal.
How to check for deprecated packages
Use the .NET CLI to check if your project references deprecated packages:
<!-- MyApp.csproj -->
<PackageReference Include="Microsoft.Extensions.Logging" Version="3.0.0" />> dotnet list package --deprecated
Project `MyApp` has the following deprecated packages
[net10.0]:
Top-level Package Requested Resolved Reason(s) Alternative
> Microsoft.Extensions.Logging 3.0.0 3.0.0 Other,Legacy
The Reason(s) column indicates why the package was deprecated. When an Alternative is listed, update to that version. Use --include-transitive to also check indirect dependencies.
In Visual Studio, deprecated packages show a warning icon in the NuGet Package Manager.
ASP.NET Core 2.3 on .NET Framework
ASP.NET Core packages used on .NET Framework require special handling. The ASP.NET Core 2.3 package list identifies the supported packages and versions for this scenario. These packages are being handled separately to ensure developers using ASP.NET Core on .NET Framework continue to have a clear path.
Timeline
This process will start in April 2026 and we expect it to be complete in the first half of 2026.
We welcome feedback on this issue. If you encounter a package that appears to be incorrectly marked, please comment here with the package name and version.
Activity
Frulfump commentedon Apr 8, 2026
Since the special care for ASP.NET Core 2.3 on .NET Framework was mentioned and it was announcement yesterday that support will end in 1 year on the 7:th of April 2027 for that will there be a new issue tracking those deprecations? There's been a few packages that hasn't been deprecated in the past just due to that niche(?) scenario. Ref: aspnet/Announcements#529 and https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of-support/
Secondly will this effort move the needle on getting the custom deprecation reason into the CLI so we don't always need to go to nuget.org to check anyways? (I created an issue in the past for that here NuGet/Home#14473)
Could we get a list of the packages before they are actually marked on nuget.org?
Some questions in the old issue seem to have been unanswered will they be addressed in this new thread?
leecow commentedon Apr 9, 2026
@Frulfump, thanks for the questions.
I'll work with Daniel on the process for ASP.NET Core 2.3. Nothing specific to add right now and will update this thread when I know more.
With respect to deprecation reason in the CLI, it currently reports the deprecation reason supplied to NuGet.org at the time of deprecation. The available options are not great and we're starting a conversation with the team to try and make that more descriptive. No commitments at this time.
Providing the list of packages beforehand during this "catch up" phase is reasonable, though nothing should be a surprise.
I'll have a closer look through #7420 and bring forward Q&A that seem relevant to address. Please do let me know if there is anything in particular that you're concerned about.
Frulfump commentedon Apr 9, 2026
@leecow Thanks for the prompt response.
In regards to the package deprecation reason I was focusing on the custom reason package authors can supply
(It also says
I think the word "owners" is wrong there it's for package consumers.)
But if you see more options for the built-in reasons that would be better that would also be good.
There's also a design for a new end of life status but that design doc has stalled in PR form. NuGet/Home#13598 it was auto closed by a bot due to inactivity, might make sense to get some design time on that since it seems to fit this area. Also relevant here NuGet/Home#13774 which covers adding a support end date ahead of time. NuGet/NuGetGallery#9837 covers highlighting EOL .NET versions. NuGet/NuGetGallery#9638 Covers adding the date(and time I hope) when packages were marked as deprecated as that info could be useful in some cases.
(There's also no unlocked mirror issue or discussion linked for aspnet/Announcements#529 where it can be discussed)
A separate list of packages(and which version) that has been moved inbox and starting from which
NET version would also be very helpful. Package pruning helps here but I don't want to have to run a restore and it's limited to opt-in for .NET 9 and enabled default in .NET 10 so for those that are still using the .NET 8 SDK (or stuck on TFMs prior to .NET 9) it won't help.
leecow commentedon Apr 9, 2026
@Frulfump we are not planning to using the custom message for deprecations so the typical reason will be "legacy".
leecow commentedon Apr 9, 2026
Here's the batch of packages we willl process first as a test.
Update: initial package list has been marked deprecated. We'll pause until next week before continuing to listen for feedback.
Varorbc commentedon Apr 13, 2026
Could you clarify why
System.Text.Jsonversions 6.0.10 and 6.0.11 were not marked as deprecated on NuGet.org?Frulfump commentedon Apr 13, 2026
I don't see the packages directly below marked as deprecated, CDN issue?
https://www.nuget.org/packages/System.Collections.Immutable/6.0.0
https://www.nuget.org/packages/System.Text.Json/6.0.0 (Just marked as vulnerable, as is versions up to 6.0.9)
For dotnet-counters there's no 6.0.0 version, the earliest is 6.0.257301 https://www.nuget.org/packages/dotnet-counters/6.0.257301 and that isn't marked as deprecated
For Microsoft.Build.Engine there's no 15.0.0, the earliest is 15.1.548 (excluding prerelease packages),
https://www.nuget.org/packages/Microsoft.Owin/4.2.0 only marked with high severity vuln but not deprecated.
https://www.nuget.org/packages/dotnet-aspnet-codegenerator/6.0.0 not marked as deprecated
The only one actually marked as deprecated from the list above is https://www.nuget.org/packages/AspNetCoreRuntime.3.1.x64/3.1.32 (and all other versions)
I guess this will be marked in an upcoming batch (Including 6.0.1 and up to 6.0.10 and 6.0.11? But interested in an official response.
I assume it will be the same for https://www.nuget.org/packages/System.Collections.Immutable/6.0.1
Why? The packages in the older cycle got this as a custom message
Which I think is beneficial for consumers. And it seems like https://www.nuget.org/packages/AspNetCoreRuntime.3.1.x64 has the message
Which is consistent with the list above, but maybe that happened as part of another process?! But referencing this issue I think would be an improvement
leecow commentedon Apr 21, 2026
The missing package deprecations were due to an error in my data source not enabling wild cards. Everything but msbuild should be correctly marked now.
With respect to the custom message, I've also updated that do be similar to the last effort and point to the announcement.
Frulfump commentedon Apr 22, 2026
Nice thanks, what's the reason for delay in regards to the msbuild package(Microsoft.Build.Engine)?
My previous note
leecow commentedon Apr 23, 2026
re Microsoft.Build.Engine, I'm chatting with the owners to understand the version ranges, consumers, and anything else I need to consider before picking the range for this first round of deprecation.
Frulfump commentedon May 19, 2026
What's the latest status here now? And for the second/remaining batch?
Frulfump commentedon Jun 28, 2026
@leecow hey just checking in on the status here :)
Frulfump commentedon Oct 5, 2026
.NET 11 releases in roughly a month so would be nice to get this sorted before the next upgrade cycle starts so more people can get rid of the packages by being informed of their status in a more obvious way.