Check for .NET NuGet Updates via dotnet outdated cli tool

.NET now has a very powerful CLI that can also handle NuGet packages very well. But one important feature is missing: check if there are package updates.

Thanks to the .NET tool dotnet outdated , developed by JerrieP and the open source community, this is still possible - even if I think this should be part of the vanilla CLI.

Installation

The tool can be installed either globally on a computer or on project level. I am a big fan of local instead of global installations. Thus, the tool is part of the solution and every developer always has the tool.

dotnet tool install dotnet-outdated-tool or as global dotnet tool install --global dotnet-outdated-tool

Usage

The tool works both with one project, but also with a complete solution and many projects.

For this purpose, only the command XX must be executed in the respective directory, then the following output appears, for example

 1PS C:\source\MyCSharp\MyCSharpNET> dotnet outdated
 2> MyCSharp.Portal.WebApp
 3  [net6.0]
 4  Microsoft.CodeAnalysis.Common                          4.0.0  -> 4.0.1
 5  Microsoft.CodeAnalysis.CSharp                          4.0.0  -> 4.0.1
 6  Microsoft.VisualStudio.Azure.Containers.Tools.Targets  1.14.0 ->
 7
 8Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?
 9
10Unable to find DOTNET_HOST_PATH environment variable. If you use credential providers for your NuGet sources you need to have this set to the path to the `dotnet` executable.
11
12Version color legend:
13<red>   : Major version update or pre-release version. Possible breaking changes.
14<yellow>: Minor version update. Backwards-compatible features added.
15<green> : Patch version update. Backwards-compatible bug fixes.
16
17You can upgrade packages to the latest version by passing the -u or -u:prompt option.
18Elapsed: 00:00:10.5041871

As you can see, this works great with public packages, but it doesn’t seem to work perfectly with private packages yet. In my case it seems to have a problem with linking certain packages directly via the file system instead of using a NuGet server.

But it’s a definite improvement in handling NuGet package information, because the current NuGet view in Visual Studio is way too slow. But it’s a definite relief when dealing with NuGet package information, because the current NuGet view in Visual Studio is way too slow.