dotnet / dotnet/core

.NET 9.0 nuget hell guidance.

Open
#9,820 3 comments 4 reactions 0 assignees View on GitHub
area-nuget Team:NuGet
Dominant language
PowerShell
Stars
22k
Forks
4.9k
Avg merge
5d 5h
Merged PRs (30d)
29

Description

In our company we maintain an internal framework that targets the following:
.NET Standard 2.0, .NET Core 3.1, .NET 6, .NET 7, .NET 8, and .NET 9.

With the release of .NET 9, we're now facing a serious case of NuGet dependency chaos—and we're looking for guidance.

What We're Seeing

🔄 Some Microsoft packages now publish up to version 9.X and claim compatibility with earlier frameworks like .NET Standard 2.0.

📌 Other packages require versioning that matches the target framework.
For example:

If you're targeting .NET 6, you have to use version 6.X
If you're targeting .NET 7, you need version 7.X

🤷‍♂️ Some packages behave inconsistently:

Some packages you can go all the way to version 8.X but not 9.X.
The weird thing is the same packages on .NET 8 they can go to 9.X.

⚠️ Misleading compatibility + build-time warnings:
Some packages claim support for earlier versions, but then generate warnings like:

```Consider upgrading your TargetFramework to netXXX or later. You may also set
true in the project file to ignore
this warning and attempt to run in this unsupported configuration at your own risk.
```

Downgrading to try to resolve these warnings often introduces other build or runtime failures.

Key Offender: **System.Text.Json**
This is a primary example of the issue:

The latest versions claim support for earlier versions (like .NET Standard 2.0),

But at runtime, they can break in subtle or severe ways unless you're on the latest framework.

Older versions that work trigger “High Security Risk” warnings in NuGet, leaving us with no good option.

What We Need

We’d appreciate official guidance or clarification on:
* What the expected compatibility behavior should be across major package versions and TFMs.
* How to approach situations where compatibility is advertised but not functionally stable at runtime.
* How to balance runtime stability against NuGet security vulnerability warnings on older versions.

We need a clear strategy or official guidance on how to navigate this mess—ideally from Microsoft or someone who's managed to successfully tame this beast. At this point, we're dealing with a dependency matrix that’s becoming impossible to maintain.

Thanks in advance 🙏

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.