Announcing NuGet 6.9
NuGet 6.9 is included in Visual Studio 2022 and .NET 8.0 out of the box. You can also download NuGet 6.9 for Windows, macOS, and Linux as a standalone executable.
In NuGet 6.9, we introduce some exciting new features and bug fixes, such as an improved multi-targeting experience in Visual Studio and support for the ‘dotnet search’ command. For more information, and a detailed list of all changes, see our release notes.
NuGet 6.9 Highlights
Support for dotnet search command
Starting with NuGet 6.9, you can now use the dotnet package search command for nuget.exe CLI experience to search one or more package sources for packages that match a search term. If no sources are specified, all sources defined in the nuget.config will be used. In addition, all available versions for a package can be listed. The command format is ‘dotnet package search [search term] [options]’.
For example, the screenshot below shows the phrase “json” is searched across all sources present in the nuget.config file.
Various different ‘options’ are available to help narrow down your search, including ‘–take’ and ‘–skip’. The screenshot below shows the phrase “json” is searched across the sources that are present in the config file. The pagination here allows the user to skip the first package and render only two packages.
By using the “–source” option, you will be able to specify the desired source of the search operation.
You can also limit available versions of a package by using the ‘–exact-match’ option, shown below.
Finally, you can also utilize the ‘–verbosity’ and ‘–format’ options to customize the output rendering.
Visual Studio UI Multitargeting Experience
In NuGet 6.9, we have made further improvements in managing packages for multitargeted projects in Visual Studio. When you have a multitargeted project, and a package is installed conditionally in every framework (for example, with different versions), conditional update will now update all conditions. Additionally, conditionally installed packages can now be uninstalled from within Visual Studio.
Closing
NuGet 6.9 comes with some exciting new features and bug fixes that will continue to improve your experience managing packages in your .NET projects!
On behalf of the NuGet team and the entire .NET community, we’d like to express our sincere gratitude to all the community contributors who have generously given their time and expertise to improve NuGet this release. Thank you.
For more details on NuGet 6.9, see our official release notes.
Feedback
Your feedback is important to us. If there are any problems with this release, check our GitHub Issues and Visual Studio Developer Community for existing issues. For new issues within NuGet, please report a GitHub Issue. For general NuGet experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem.
Light
Dark
5 comments
Unfortunately, the VS UI still doesn’t detect when the latest version of a referenced package doesn’t support the current target framework.
For example, it’s still suggesting that I update my .NET 6.0 project to reference Microsoft.AspNetCore.Mvc.Testing v8.0.2, which only supports .NET 8.0 projects.
That makes updating NuGet references in Visual Studio a horrendously painful experience. I have to select each one in turn, check to ensure that it and all of its dependencies support the project’s TFM, then update one at a time.
It’s particularly bad in .NET Framework web projects, where every transitive dependency is directly referenced. You can’t update X because it depends on a later version of Y than you have referenced, so you need to work out which is the “top level” dependency that needs to be updated first.
Yes this is frustrating. I vaguely remember a blog or something posted last fall (?) about making the UX (and presumably CLI) smarter when it displays upgrades to start looking at TFM compatibility. But I haven’t seen any additional information and it is such a complex problem that I’m not convinced it is going to work in all cases. For example a package says it supports a TFM but that doesn’t mean it’ll actually work in my app. For example I may be able to upgrade to v2 of a package because it supports my newer TFM but another package relies on v1 and doesn’t support v2 and cannot be upgrade. It seems like it would get messy real fast.
There are also cases where packages are just known to introduce problems and therefore I don’t care if it is the new version or not, I’m not upgrading. What I really want is the ability (at least in the UX) to say that I don’t want to upgrade to this version and it should stop showing it as an option for me in this project. When a newer version comes out then it can prompt me again. Right now every time I return to a project I have to look at the list of upgrades and try to remember if it is OK to upgrade or not. We have a wiki that helps us track packages and which versions are problematic or things to check. I’d rather that be more self-contained.
The link to the release notes don’t work (need authentication). Maybe the correct link is :
https://learn.microsoft.com/en-us/nuget/release-notes/nuget-6.9
So many bug fixed, thank for your work.
nice
This new feature, “Allow floating versions with Central Package Management (CPM)” deserves a honorable mention.