Posted by It’s been ten years since the release of NuGet, .NET’s package manager, and working with it can sometimes be fraught with difficulty. Okay, I’m exaggerating a bit. But the reality is that there isn’t a single best way of installing, updating and removing packages in a solution — they all have their pros and cons.
Here’s a summary of what works best for me, based on the context of what I’m doing:
| Method | Use this approach if… |
|---|---|
| Package Manager | – You’re not sure which package or version you need. – You want to look for related packages on NuGet. – You want to consolidate package versions for a project. |
| Package Manager Console | – You want to re-install a package version in a project. – You’ve copied the install command from a NuGet repository. – You need to update the package version across many projects. |
| Edit *.csproj | – You know specifically what package and package version you need – You want to remove a package from a project. |
| dotnet CLI | – You’re not working in Visual Studio and need basic add/update/remove functionality. |
These rules of thumb help me be more productive by making use of the best parts of each of those approaches. Let’s look a bit more closely why I do things like this.
Package Manager
I couldn’t find any statistics to back this up, but Package Manager must be the #1 way that packages get updated in Visual Studio. The UI hasn’t changed all that much since it was first released, and while functional, it still has occasional hiccups.
The search bar is great to explore packages and versions of project’s that you’re not familiar with. You can easily search on NuGet or a private repository for any related or similar packages. On the other hand, going through the UI is going to slow you down when you know exactly what you need. So I only use it when absolutely necessary.
The Consolidate tab is the most useful feature of Package Manager. It lets you quickly fix any package versions that aren’t in alignment, avoiding the potential for the solution to fall into “NuGet Hell”. I’m not aware of any other way to accomplish this short of doing it all manually.
Package Manager Console
Most NuGet feeds give you the option to copy an Install-Package command directly from its UI. For example, on NuGet, you’d see something like this:
Private NuGet feeds hosted on Azure DevOps or elsewhere usually have something similar to copy the install command.
The only downside here is that installing to more than one project requires re-executing the Install-Package command on each project; otherwise a project is installed to the default project only. The opposite is true for Update-Package, which updates all projects that reference the package. It’s a fast way to update a package across a large solution.
The PM Console is at its most useful when you need to force reinstall a package. It’s a one-liner from the console: Update-Package PackageName -reinstall. There is no direct way to do this from the UI, other than uninstalling and reinstalling the package.
dotnet CLI
I work almost exclusively in Visual Studio for building .NET applications, and therefore barely use the CLI. There appears to be more flexibility from the Package Manager Console, which is a bit surprising considering so much effort has been put into the CLI.
Manual Editing of Project File
The final way to update a package is by manually editing the project file’s PackageReference entries. Often times, all you need to do is replace a version number, and if you already know what that version number is then it’s quicker to edit the project file yourself and hit Rebuild. Start by doing a search for the package in question in Find In Files (Ctrl-Shift-F):
<PackageReference Include="{PackageName}"
And then just update the version number for every reference found. You could also do a Find & Replace to perform the update on all matching packages.
All Roads Do Not Lead To NuGet
As we saw, none of these solutions are perfect or work in every scenario. There is however a nice balance to be achieved by combining each of these strategies together.
Another option that’s worth exploring is Paket, an open source alternative to Microsoft’s provided tooling. Or if you don’t want to venture outside of NuGet’s tooling ecosystem, but are willing to try a different IDE, Rider’s package manager seems fairly intuitive and flexible.
I hope a more complete NuGet package management alternative comes along at some point, but until then, I’ll keep mixing and matching my package management strategies.
Marc Roussy 