November 13th, 2020

Getting Started With NuGet 5.8

Jon Douglas
Principal Program Manager

Getting started with NuGet 5.8

NuGet 5.8 is included in Visual Studio 16.8 and .NET 5.0 out of the box. You can also download NuGet 5.8 for Windows, macOS, and Linux as a standalone executable.

NuGet 5.8 is one of many releases in our .NET unification journey. Our NuGet tooling helps developers discover new .NET packages to use for their .NET applications, while making package management easier during your daily development.

NuGet 5.8 Highlights

There are many important improvements in NuGet 5.8:

.NET 5 Support

NuGet 5.8 is the first release to offer full authoring and restoring support for NuGet packages targeting .NET 5.0.

Image dotnet

If you aren’t familiar with the .NET 5.0 target today or what it will look like in the future, don’t forget to check out this great post by Immo Landwerth on The Future of .NET Standard.

MemoryMappedFiles for Faster Writes

By using mmap for .nupkg extraction during restore, we’ve been able to improve the write speed of files holistically on Windows.

For example, when running NuGet restore with mmap against the Orchard Core project:

MMAP Improvements

Client Scenario Time in Seconds
no mmap cold 64.08216
mmap cold 22.03339
no mmap warmup 64.58149
mmap warmup 32.60708

You’ll notice there is a 65% performance improvement for cold(Http Cache) and 50% performance improvement for warmup(No Http Cache) scenarios. We hope that you’ll enjoy these performance improvements when using NuGet 5.8.

NuGet CLI Search Command

Find NuGet packages quickly through the NuGet CLI with nuget search.

Image nugetsearch

Image nugetsearchlogging

To see additional examples, see the documentation for nuget search.

No-Op Restore Optimization

A no-op restore is when NuGet checks every project in a solution to ensure that nothing has changed & determines whether a partial or full NuGet restore will be needed to install all of your dependencies.

In NuGet 5.8 & Visual Studio 16.8, we added optimizations to projects using <PackageReference>. This has brought significant gains to how long a no-op restore takes against an existing solution.

For example, when running NuGet restore multiple times against the Orchard Core project:

NuGet Restore

Tool Version Restore Time in Seconds
dotnet CLI 3.1.402 noop 6.929698
dotnet CLI 5.0.100 noop 5.792257

You’ll notice there is almost a 15%+ performance improvement to no-op restores between .NET 3.1 & .NET 5.0. Additionally, you’ll see less of a difference between the performance of your no-op restore when restoring using other methods such as NuGet CLI, MSBuild, and Visual Studio.

dotnet list package –verbosity

You can now turn up the MSBuild verbosity level when listing packages for your project or solutions.

Image dotnetlistpackage

To see additional examples, see the documentation for dotnet list package.

dotnet add package –prerelease

The dotnet add package command installs the latest stable version by default. You can now install the absolute latest version if you include the –prerelease option.

Image dotnetaddpackage

To see additional examples, see the documentation for dotnet add package.

dotnet nuget verify

You can now verify a NuGet package that has been signed within the dotnet CLI. In the future, you will be able to sign a NuGet package with the dotnet CLI.

Image dotnetnugetverify

To see additional examples, see the documentation for dotnet nuget verify.

NuGet Solution Load Performance Improvements

You may have encountered the dreadful delay of loading big solutions in Visual Studio. Much of that time can be dedicated to loading your projects and restoring your packages when you first open your solution. In NuGet 5.8, we improved 2 main areas:

  1. We’ve reduced the amount of NU1105 errors you see when loading your solutions in Visual Studio.
  2. We’ve improved no-op restore performance by 10%+ when loading a solution.

Let us know if you see less errors & a faster solution load experience with NuGet!

Visual Studio Package Manager Improvements

In NuGet 5.8 & Visual Studio 2019 16.8, we addressed a problem in which projects are continuously restored. We optimized this to only restore once while also running in parallel. You should notice your NuGet Package Manager UI to perform much more quickly as a result. In fact, you may see somewhere between a 2-14x faster experience when using the NuGet Package Manager UI with more optimizations coming soon.

We’ve also improved your experience when using the consolidate and update package operations. Instead of having to try several times to upgrade or downgrade a package version, we’ve improved the reliability to ensure that you only have to do this operation once to restore correctly.

Finally, we’ve made it much faster to uninstall packages for large solutions. For example, a project such as Orchard Core includes 158 projects in a solution. To uninstall packages in this solution previously would take around 70s. We’ve improved this performance by 2x so it only takes 30s for 158 projects. You will also see this improvement for your smaller solutions where a small solution with 4 projects might take 1s to uninstall. It now will only take 0.75s.

Known Issues

Because NuGet 5.8 is the first release to support .NET 5, we consider it to be a known issue that your builds can break when using it with other tooling versions. You may run into issues with restoring your projects & solutions and then building them using mismatched versions of tooling.

One such issue you may run into is NETSDK1005. This happens when you restore packages using an earlier NuGet tooling version & building your projects & solutions with a newer tooling version of Visual Studio, dotnet CLI, or MSBuild.

It is advised to ensure that you are on the same version of tooling in your environments. Visual Studio 16.8, MSBuild 16.8, and .NET 5.0 require NuGet 5.8 or later.

One such way of ensuring you have the same version of tooling being used in your environments is to use MSBuild, Visual Studio, or the dotnet CLI. You can get started with NuGet restore in each of these scenarios in the following way:

Closing

NuGet 5.8 is a big release that should improve many aspects of your daily package management needs. We’ve added a broad set of improvements to our CLI experiences, improved performance to restore & solution load, and added support for .NET 5!

We’re excited to see you use NuGet 5.8 & include it in your toolset for building amazing things with .NET.

For more details on NuGet 5.8, 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.

Author

Jon Douglas
Principal Program Manager

Jon Douglas is a Principal Program Manager for NuGet at Microsoft. In his spare time he is most likely spending time with his family, performing comedy improv, or playing video games.

8 comments

Discussion is closed. Login to edit/delete existing comments.

  • Tristan Barcelon

    Jon, you’ve mentioned on the post Nuget 5.8 command line being available for Windows, Linux, and MacOS. However, when I follow the hyperlink or when I go to https://www.nuget.org/downloads, all I see are windows executables. Were you referring to the nuget action in dotnet as the proxy for Nuget 5.8 CLI in Linux and MacOS?

  • Piotr Kula

    Hello-
    What is the time line to get NuGet 5..8.0 as the main release.
    Cake (C# Make) is pulling latest and bringing down 5.7.0 and resulting with the error mentioned here. We have to manually take 5.8.0 to fix it so just wondering how long we need to be doing that?

  • Dominik Jeske

    MemoryMappedFiles is an interesting topic for me. Do you have some more information’s you can share – I have not saw this topic in .NET Core area. Is there any best practices/guide for community?

  • Maxime Savard

    Cool I wait for NuGet.CommandLine

    • Jon DouglasMicrosoft employee Author

      We’re on it! Thanks for reminding us.