As part of our ongoing commitment to improve the NuGet ecosystem, today we are excited to introduce a couple new features on NuGet.org to help you determine if a package is compatible with the target frameworks you know and love. This is how it looks:
You will now have a new “Frameworks” tab on any package details page.
This will give you a table of all provided assets based on the .NET product and version. In addition to compatible target framework assets, we also compute target frameworks that will be compatible given the current assets provided.
In addition, you’ll now see target framework badges at the top of the package details page to understand at a glance what products and minimum version of .NET the package provides assets for.
What’s the Difference?
For newer members of the .NET family, there’s quite a bit of confusion about .NET Framework, .NET Core, .NET Standard, and .NET. How do they differ from one another and what should you look out for when choosing a NuGet package that meets your project’s needs?
As .NET 6 unified the platform for browser, cloud, desktop, IoT, and mobile apps, the NuGet package ecosystem is still diverse in supported target frameworks from each generation of .NET’s development. If you aren’t familiar with each major .NET release, here’s a table for your reference:
OS | Open Source | Purpose | |
---|---|---|---|
.NET Framework | Windows | No | Used for building Windows desktop applications and ASP.NET Web apps running on IIS. |
.NET Core | Windows, Linux, macOS | Yes | Used for building cross-platform console apps and ASP.NET Core Web apps and cloud services. |
Xamarin | iOS, Android, macOS | Yes | Used for building mobile applications for iOS and Android, as well as desktop apps for macOS. |
.NET Standard | N/A | Yes | Used for building libraries that can be referenced from all .NET implementations, such as .NET Framework, .NET Core and Xamarin. |
.NET | Windows, Linux, macOS, iOS, Android | Yes | Used for building cross-platform console apps, ASP.NET Core Web apps, cloud services, mobile applications, and more. |
NuGet and Target Frameworks
When you target a .NET framework in your app or library, you are specifying the set of .NET APIs that you’d like to make available to them. You do this through what is known as a target framework. Each target framework has it’s own unique moniker known as a target framework moniker(TFM), giving them an easy to remember short-form name.
These TFMs tell NuGet what assets to select from the package to then be used within your project. If multiple sets of assets are available in a package under different frameworks, NuGet must choose between these frameworks with an order of precedence.
For example, the preference of targeting .NET 6.0 / net6.0
would be:
What this means is that if NuGet is unable to find assets with the respective short folder name that matches the TFM, it will continue down the order of precedence until there is a match.
Closing
We hope that this feature will help improve your productivity of discovering and consuming NuGet packages and would like to thank everyone who helped us deliver this feature from an original concept on GitHub over 4 years ago to today.
This is just the beginning of our journey to improve NuGet and make your package compatibility experiences better than ever with the tools you know and love. Stay tuned for more exciting developments from our team to you in the near future. Till then.
Feedback
Since compatibility is a complicated area and we’re still learning, we need your feedback more than ever to ensure these features can meet your expectations. The best way to give us that feedback is a comment on this post and filing an issue on GitHub.
Your feedback is important to us. If there are any problems with this feature, check our GitHub Issues. For new issues within this experience, please report a GitHub Issue.
TFM badges on the top of package details is nice enhancement.
But Visual Studio 2019/2022 still suggests package upgrades to vesions that are incompatible with project TFM (for example upgrade Microsoft.EntityFrameworkCore 5.0x -> 6.0.x for a project targeting .NET 5).
I cannot retarget my project from .NET 5 to .NET 6 because VS 2019 lacks .NET 6 development support and VS 2019 cannot be upgraded to VS 2022 (installed with the same license key).
+1 for this! VS2022 keeps suggesting I upgrade EF Core to v6 on projects targeting .NET Framework 4.8 or .NET Standard 2.0; if you don't realise, and try to update, it spins its wheels for a while before bailing, and you have to dig into the output window log to find out what the problem is.
Limiting the package manager's update and install suggestions to versions which are actually compatible with the current target framework would...
Thank you both!
This is definitely an area on the radar to help address these compatibility scenarios and also stop notifying you that there's updates that you can't actually take on in your projects.
Ideally we would match based on TFM compatibility and you as the user wouldn't see any incompatible upstream or downstream packages unless you had a setting enabled to show everything. If there's any other thoughts around this area, please let me know so...