Introducing Search By Target Framework on NuGet.org
Last year, we brought a new feature to improve the way you assess target framework compatibility of a NuGet package through a new “Frameworks” tab.
Today, we are announcing a new feature that will allow you to search by a target framework on NuGet.org. Here’s how it looks:
The first thing you might notice is that there is a new “Frameworks” filter on the left where you can select from a collection of .NET frameworks you’re interested in a package providing assets for.
Selecting .NET in this example will match packages that are built for modern .NET including net5.0 through net7.0 and provides at least one of these versions with a framework asset respectfully.
If you’d like to get more specific about the version, you can expand the parent element and then select a combination of known target frameworks.
One key design principle in the .NET framework is backwards compatibility, which enables developers to upgrade their applications and packages to newer versions of the framework without having to completely rewrite their code.
Whether you are looking for compatible packages on the latest .NET framework or packages still targeting the framework you are, this feature is here to help.
Finally, you may have noticed some elements were moved on the search page. We wanted to take this opportunity to put filters in a logical place where they’re always available and we moved the sort options to a more accessible location. In short:
Wait…What’s a Target Framework Again?
A target framework is a .NET framework that a NuGet package is built and designed to work with. When a package is created, the developer specifies which target framework(s) the package supports. The target framework is typically specified using a specific .NET Framework, .NET Core, or .NET Standard version.
For example, if a package specifies that it targets the .NET Framework 4.6 (net46 for short), that means the package is built and designed to work with applications that are built using the .NET Framework 4.6 or higher.
If a developer upgrades their project’s target framework to .NET 4.7, they may need to update the NuGet packages they use to maintain compatibility and ensure their application continues to work as expected.
If a package targets .NET Standard 2.0, it means that the package is built and designed to work with any runtime that supports the .NET Standard 2.0, including .NET Framework, .NET Core, and .NET.
When a developer installs a package in their project, they can specify the target framework they are using, and NuGet will check that the package is compatible with that framework. This ensures that developers can use packages that are designed to work with the framework they are using and can also ensure that packages do not have any versioning conflicts.
What’s Next?
The next step in this feature area is to bring this target framework awareness to the NuGet protocol so that clients like Visual Studio and CLI tooling can also provide rich experiences for filtering packages.
In addition, .NET has been growing the number of platforms these target frameworks support over the years and we want to make it easier for you to find packages based on more helpful factors such as platforms a target framework supports and their respective platform versions.
Feedback
We are continuously working to improve NuGet and NuGet.org to better meet the needs of the community. We would love to hear your thoughts on this feature, including any feedback you have on it, what would be most helpful to you, and any potential challenges you run into. Your feedback is essential in helping us ensure that we are building the right features to meet your needs, and we thank you for taking the time in sharing your thoughts with us.
Jon Douglas Principal Program Manager, NuGet
Light
Dark
6 comments
“… clients like Visual Studio and CLI tooling can also provide rich experiences for filtering packages”
Does that mean VS will finally stop suggesting that I update packages to a version that’s not supported by my target framework? (Looking at you, EF Core.)
If so, YES PLEASE! Can we have it yesterday? 🙂
This is a goal long term. We’d like to be able to have a smarter client experience that is TFM-aware. That way you’re only provided updates for the generation of .NET you’re targeting until you’re ready to upgrade.
The relevant issue I believe is here: https://github.com/NuGet/Home/issues/6566 (Go upvote it and comment!)
It’s welcome.
Just the multi selection operate like a AND (and not a OR). I would preferred the OR behavior.
A improvement idea, it’s the possibility to search a package compatible to a target framework. When I choose .NET Framework 4.8, the result displays packages that target :
Thank you kindly. Would you mind filing an issue here on the OR behavior? We debated this multiple times and need to hear what the community would like it to be.
https://github.com/NuGet/NuGetGallery/issues/new/choose
As for the computed compatibility, we have an issue here to add this:
https://github.com/NuGet/NuGetGallery/issues/9372
It’s nice, but to be honest, in its current state it’s not as useful as it could be.
Basically, it searches only by explicitly targeted TFMs, not by compatible TFMs.
For instance, if I have an app targeting .NET 6.0, I would expect that when I check .NET 6.0 in the search filters, it returns all packages that are compatible with .NET 6.0, not just those that explicitly target .NET 6.0. For instance, if a package targets .NET Standard 2.0 or .NET 5.0, it can be used in an app that targets .NET 6.0.
Thank you for the comment.
We wanted to get something out and iterate with feedback. We are tracking this specific item here https://github.com/NuGet/NuGetGallery/issues/9372
This will likely be added as a toggle switch of exact vs. computed matches.
Go upvote it!