Azure Devops Nuget restore fails with "unable to load the service index for source"

user_981831 0
Viewed 1075

We have an in-house Azure DevOps 2019 server and I'm currently setting up a build for a new .Net6 solution whose projects reference various packages from both nuget.org and an in-house feed in our ADO server's "Artifacts" area.

With this being .Net6, I'm assuming I have to use the ".Net Core" restore task (black square icon), rather than the older "NuGet" restore task (blue icon)? I've therefore added the former, and configured the pertinent settings as seen below, where "NuGetPackages" is the name of our in-house feed:

enter image description here

When I run the build, this task is failing with the message

error NU1301: Unable to load the service index for source http://***/_packaging/2df3c440-07a5-4c01-8e5c-bfbd6e132f09/nuget/v3/index.json.

The URL of our in-house feed is: http://***/_packaging/NuGetPackages/nuget/v3/index.json, so why has the feed name in the URL been replaced with a GUID as seen in the error message? Presumably this is why the restore fails.

Incidentally we have numerous .Net Framework 4.x solutions that reference the same packages and build fine. These use the older "NuGet" (blue icon) restore task, but the settings are identical to those in the above image, suggesting that the newer ".Net Core" task is doing something strange.

(As an aside, could someone explain the difference between the "NuGet" task and the ".Net Core" task? Could I still use the older task in my .Net6 build pipeline? I tried it briefly earlier but it complained that msbuild v17 isn't installed and didn't want to continue down that path for fear of breaking the 4.x builds).

nuget-package-restore azure-pipelines azure-devops
1 Answers

I just spent nearly two days fighting this same NU1301 error, and while my ADO instance is cloud-based and the "latest", i.e., not exactly analogous to your situation, maybe my experience will shed some light.

The tldr; is that there were permission issues for the ADO "project" build service account accessing the "organization" Artifact feed. The output from the DotNetCoreCLI@2 restore task didn't even hint in that direction, but when I dropped-back to using the NuGet restore task, the error messages were more informative and helped me discover the underlying issue.

This info doesn't shed light on the guid/name swap issue you ask, but maybe the guid is an internal ID that is first used to then resolve the name, and if a permissions issue prevents even querying the Artifacts endpoint ...

As for the msbuild v17 comment, I would heed very carefully this advice and your trepidation about messing with the existing builds. To paraphrase that old quip ... it's not really paranoia, if MS has a well-established history of breaking stuff that has worked just fine for a very long time! ;-}

HTH.

SC

user_57867020
Related