Report Out Of Date NuGet Packages

Fail your CI build if there are any NuGet packages out of date in your project with dotnet-outdated.

Boris Donev
3 min readJan 31, 2021

If for some reason you cannot or don’t want to set up an automatic update of your NuGet packages, there is also a reporting option possible. You will know which packages are out of date, and you can additionally choose to fail your CI build so the developers will need to update them before the pull request is integrated. This, of course, is viable for smaller teams. You could also have a weekly build, and maybe produce weekly task for NuGet package updates without blocking any code integrations.

For this, we will use dotnet outdated - a dotnet core tool which reports outdated NuGet packages. We’ll use it on an on-premise Azure DevOps server, but you can easily integrate it on pretty much any DevOps solution.

Since dotnet outdated is a third party tool, we have to first install it on the agent. We will use the .NET Core Global Tool installer step for that, which can install any dotnet core tool. Just add the name and version as on the screenshot below.

In case you have private feeds, and to be sure that the “outdated” step below won’t fail because it cannot restore packages, you’ll need to also add a “dotnet restore” step. This is just the reguler .NET Core step with the restore command.

Next, we add a standard .NET Core step again, and execute a custom “outdated” command on all the projects in our solution, as in the screenshot below. We use the “-f” argument to return a non-zero exit code so the step will fail in case there are out of date NuGet packages. This way we force the developers to update any out of date NuGet packages. We would also want to include only packages where the new version is older than 14 days, by using the ”-ot” argument. We do this just in case a new version of a package has bugs and is quickly patched, we avoid installing it. This is a feature I actually contributed to this project, yay!

There are many other options, including private feeds, include and exclude packages and so on. You can read more and configure the way you want it here.

Result

If any of your packages are not up to date according to the arguments you specified, you’ll see this:

One we update the packages and run the command again, it will pass.

One thing to note for existing users of “dotnet-outdated” is that this tool’s repository was handed over and deleted some time ago, and now goes with the name of “dotnet-outdated-tool”. So if you already have the old “dotnet-outdated” installed, you need to uninstall it before installing “dotnet-outdated-tool”.

Conclusion

While I would prefer automatic updates, and actually use them with success, there might be reasons against it. Dotnet-outdated will still give you the possibility to keep the NuGet packages in your project up to date, albeit with a little bit of manual work. The most important thing is that you can enforce the upgrading, as if you don’t enforce things with policies, consider them forgotten after a while.

--

--

Boris Donev

As a technical team lead of several startup projects, I've come across different issues which I'll try to document and maybe help someone else.