Check for .NET NuGet Updates via dotnet outdated cli tool

Check for .NET NuGet Updates via dotnet outdated cli tool

Check for .NET NuGet Updates via dotnet outdated cli tool
dotnet | nuget

.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

PS C:\source\MyCSharp\MyCSharpNET> dotnet outdated
> MyCSharp.Portal.WebApp
  [net6.0]
  Microsoft.CodeAnalysis.Common                          4.0.0  -> 4.0.1
  Microsoft.CodeAnalysis.CSharp                          4.0.0  -> 4.0.1
  Microsoft.VisualStudio.Azure.Containers.Tools.Targets  1.14.0 ->

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?

Unable 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.

Version color legend:
<red>   : Major version update or pre-release version. Possible breaking changes.
<yellow>: Minor version update. Backwards-compatible features added.
<green> : Patch version update. Backwards-compatible bug fixes.

You can upgrade packages to the latest version by passing the -u or -u:prompt option.
Elapsed: 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.