Few days ago I had strange situation with NuGet restore on one of my Azure DevOps build pipelines. When I upgraded my .NET class libraries from .NET Standard 1.6 to 2.0 my build failed. My local build in Visual Studio or with bare-metal msbuild worked just fine.

Only on my Azure DevOps build pipeline I got some strange error when restoring NuGet packages.

Let’s take a look what was going on and how I fixed the problem.

.NET Standard 1.6 class library and Azure DevOps pipeline.

For the purpose of testing and experimenting I created one simple console application (.NET Core 3.1) with one class library (targeting .NET Standard 1.6) project dependency. Picture below depicts my testing environment in Visual Studio Solution Explorer.

I pushed everything on my git repository and create one simple build pipeline on my Azure DevOps:

Nothing fancy here, just pulling source code from my git repository, restore NuGet packages and build solution. Build output is as follows:

Everything is ok.

Let’s take a look what happens when I upgrade my dependency class library project to .NET Standard 2.0.

.NET Standard 2.0 class library and Azure DevOps pipeline.

I simply upgrade my class library to target .Net Standard 2.0. I modify my project file by changing target framework node in project xml definition.

My solution looks like this now:

I trigger my Azure DevOps build, and…I get NuGet restore error!

At first, I got stacked here, but after a little research I find out that Azure DevOps has relatively old default NuGet version.

Enforce Azure DevOps build pipeline to use latest NuGet

At the end, I just need to tell Azure DevOps to use latest (or at least one of the latest versions of NuGet). For this, special task exist in Azure DevOps, entitled “NuGet tool installer“.

You can check available NuGet distributions here: https://dist.nuget.org/tools.json.

Afterward, I trigger build again and everything works as expected. As shown on picture below.

Conclusion

If possible, You should always upgrade NuGet to the latest version on Azure DevOps. This way you can avoid awkward situations as described in this blog post.

Although, it looks very simple and stupid case/solution, it can cause many headaches if you run into this problem.

Happy coding.