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

Question

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:

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

Amnion

Answer 1

Something that hasn't been mentioned here, but has been the source of my pain when trying to restore from a feed in a different project but the same organization was certain settings of the consuming project... (sic. https://developercommunity.visualstudio.com/t/restore-nuget-task-unable-to-load-the-service-inde/1337219)

After adding the pipeline permissions to the NuGet feed (as per https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions), you need to update the Limit job authorization scope... settings in the project which is restoring the feed.

Chemarin

Answer 2

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

Caroche

Mine did eventually start working. I'd tried that many things though that I'm not sure what did the trick. I suspect it was installing the .Net "build apps" SDK v6.0.301 from here: dotnet.microsoft.com/en-us/download/dotnet/6.0) on the server. I did also install VS2022, so it could be that. Since installing these I've found that the older "NuGet" restore task now works, and found that it is substantially quicker (9s vs 45s) than the newer ".Net Core" restoer task. – Amnion

I also ditched the ".Net Core" build and test tasks and use this 3rd-party extension: marketplace.visualstudio.com/…. This provides VS2022 equivalents of the "Visual Studio" build & test tasks. Again these are a good 2-3x faster than the newer .Net Core tasks. – Amnion

Thanks for the link to the new build tasks! 8-} – Caroche

Answer 3

We had this same error. The GUID in the URL was a legacy alias of an Azure Artifacts feed.

In the dotnet restore build task in the failing pipeline, the field "Use packages from this Azure Artifacts feed" was blank. Setting to the desired feed resolved this issue.

Cheryllches

Answer 4

In my case, I added a permission on the source feed, to grant "Feed reader" role to the target project build identity. The build identity follows the naming convention:

"{Project Name} Build Service ({Org Name})"

Navigate to the feed, click the gear icon (Feed settings), click "Permissions" and click "Add users/groups". Now add the build service.

You can read about it here: https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions

And build identities here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml#scoped-build-identities

The consuming pipeline may need to run the NuGetAuthenticate task:

 - task: NuGetAuthenticate@1

Livorno

Answer 5

Just had the same issue recently, which appears to now be caused by the important information callouts on the DotNetCoreCLI task:

The NuGet Authenticate task is the new recommended way to authenticate with Azure Artifacts and other NuGet repositories. The restore and push commands of this .NET Core CLI task no longer take new features and only critical bugs are addressed. See remarks for details.

When connecting to a feed in the same organisation as the project pipeline, adding the following task before attempting to call the DotNetCoreCLI tasks resolved the errors for us:

- task: NuGetAuthenticate@1
  inputs:
    forceReinstallCredentialProvider: false # Default, feels wrong to call without inputs

Once I'd completed that, I needed to either turn off the "Limit job authorisation scope to current project" setting for both release and non-release pipelines, or set up access to the feed correctly:

At either the Organisation or Project level (depending on where you've created your feed), create a new Group (Settings | Permissions | Groups), and add your project-level build service to it - the easiest way is to start typing the name of the project in the user search box, it should list something like [ProjectName] Build Service ([OrgName]).

You can then add the group as a "Feed Reader" to the relevant Artifact Feed.

If you need to connect to an external organisation, you can provide a list of nuGetServiceConnections that use appropriate Personal Access Tokens to connect.

Repulsion

Answer 6

Here are the steps that helped me fix this same issue in Visual Studio.

1. Make sure that you have Owner or Contributor permissions to the Feed in Azure DevOps. Something like this:

2. Then in Visual Studio make sure that you are signed in using the account that has the permissions from the previous step.

3. Finally rebuild the solution.

Hopefully this fix your issue too!

Schwerin

Keywords here are Azure Devops - two different environments :) – Breastbeating

Answer 7

I was having this issue, and it turns out that it was the company firewall that was blocking the connection to the artifact feed. It seemed intermittent because sometimes I was on the VPN and other times I was not.

Saxton