Blog

Solve 401 (Unauthorized) error when restoring packages using VSTS Package Management and .NET Core

26 Dec, 2016
Xebia Background Header Wave

For the quick answer jump directly to the conclusion

Yesterday I was setting up the build for an ASP .NET Core (Web API) application I wrote, this application was using a package from the VSTS Package Management repository.
To setup this build I was using the new dotnet Core tooling (in preview) which is available when creating a new Build Definition:

The build task was like this:

As I said before my application was using a package hosted in the VSTS Package Manager Repository, so I added a Nuget.config file in the folder containing the project dependent on that package with the package sources defined in it:

And then I started the build.
Unfortunately I got a 401 (Unauthorized) error during the package restore:

The message is clear, the task was unable to authenticate to the VSTS Package Management Repository.
To solve the problem I thought it was just a matter to generate a PAT (Personal Access Token) and save it in the Nuget.config previously created.
But according to the Microsoft documentation the NET Core’s dotnet restore command doesn’t currently support encrypted credentials, so I will need to specify a Personal Access Token in plain text.
Really? I mean, really!?!?
I don’t want to do that. I don’t want to save passwords, tokens etc..of any kind in clear text and in source control!
Fortunately reading further ahead I saw this lines:

Note that as of NuGet 3.4.0, the nuget restore command can be used in place of the dotnet restore command. nuget restore works with any of the auth mechanisms outlined on this page.

So I replaced the .NET Core Restore Task with the Nuget Restore Task and restarted the build:

As you can see the Restore Task seems to be working now, but the build Task is failing now:

It seems to be that the package restore for .NET Core isn’t working well.
But wait a moment, the documentation said starting from Nuget 3.4.0 the Nuget could be used, but if we look at the Restore Task log we see that nuget 3.3.o is being used.
Let’s take a look in the advanced options of the Nuget Task:

Here we can select a version higher than 3.3.0 and even higher than 3.4.0, let’s give it a try!

Now if I start the build again, it will work smoothly, problem solved:

Conclusion

The easiest way to solve this problem is to replace the .NET Core Restore task and use the Nuget Restore task and to set the version to 3.5.0 – build 1938 (rc2) in the advanced properties.

Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts