58

I have a build for a .NET solution that is running in a private agent. The solution contains both .NET Core 2.1 and .NET Standard 2.0 projects.

Some of the nuget packages installed are the following:

  • NETStandard.Library v2.0.3
  • Microsoft.AspNetCore.Mvc v2.0.0
  • Microsoft.NETCore.App v2.1.5

The build fails when trying to restore the nuget packages with the following error:

"F:\Agent01\w\141\s\xxxxxxx.sln" (Restore target) (1) -> (Restore target) -> C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : Unable to load the service index for source https://xxxxxxxxxx.pkgs.visualstudio.com/_packaging/xxxxxxxxxx/nuget/v3/index.json. C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : Response status code does not indicate success: 401 (Unauthorized).

Build task is the following:

Nuget restore build task

This is the content of %appdata%\NuGet\nuget.config file in the build agent:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="MyFeed" value="https://xxxxxxxxxx.pkgs.visualstudio.com/_packaging/xxxxxxxxxx/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <MyFeed>
      <add key="Username" value="LocalBuildAgent" />
      <add key="ClearTextPassword" value="xxxxxxxxxxx" />
    </MyFeed>
  </packageSourceCredentials>
</configuration>

I already checked a few similar questions but so far I wasn't able to find a solution for my problem.

Some notes:

  • Personal Access Token is NOT expired
  • This particular build runs successfully in other build agents
  • There is at least 1 build with a "nuget restore" task that was run successfully using this agent (regular nuget restore task, NOT .NET Core)
  • Tried restarting the build agent, without success
  • Tried specifying a specific version of nuget before the restore, without success
  • .NET Core SDK latest version in the build agent is 2.1.500 (multiple versions installed)

What am I missing? How to fix this issue? Why can't I restore the packages using the dotnet restore command?

UPDATE:

Packages are restored without errors when using the old Nuget Restore task as follows:

Build definition

UPDATE 2:

I am able to restore the packages using the .NET Core task v1:

Screenshot - restore packages using the .NET Core task v1

Or using v2 task with argument --force:

Screenshot - restore packages using --force

Rui Jarimba
  • 11,166
  • 11
  • 56
  • 86
  • have you got the url correct since the devopsification? I know things have moved, where does it say your source is in the artifacts tab? for example mine is now: https://pkgs.dev.azure.com/account/_packaging/feedname/nuget/v3/index.json, still looks similar – Luke Duddridge Nov 22 '18 at 13:21
  • @LukeDuddridge yes, I believe the package source URL is correct. – Rui Jarimba Nov 22 '18 at 14:16
  • I found the similar issue on the Github, it said this issue should be fixed at 4.8, but I found that you have use the 4.8.1. https://github.com/NuGet/Home/issues/5265. If you can reproduce this issue steadily, you can reopen this issue. – Leo Liu Nov 23 '18 at 09:47
  • @leo-liu-msft I tried again running the "`Use NuGet 4.8.1`" task before "`dotnet restore`" task, without success – Rui Jarimba Nov 23 '18 at 11:24
  • @leo-liu-msft I forgot to mention that I am able to run the command `dotnet build` successfully, i.e. packages are restored when running this command. This is a possible workaround, but I want to avoid asking the developers to change all their build tasks/task groups. – Rui Jarimba Nov 23 '18 at 11:32
  • @leo-liu-msft added more details. Could this issue be related to the nuget endpoint, somehow? All the workarounds I tried don't seem to use the nuget feed. – Rui Jarimba Nov 26 '18 at 10:21
  • Update: the same issue is now happening when using a different agent, it started today – Rui Jarimba Nov 26 '18 at 16:20
  • 2
    @RuiJarimba using Nuget 4.8.1 solved my issue with this. I had the issue occur after we turned on the new devops url. – cal5barton Feb 13 '19 at 22:58
  • @cal5barton good stuff, thanks for sharing – Rui Jarimba Feb 14 '19 at 07:43
  • @cal5barton you should post your comment as an answer, it might help other people. Many probably won't bother to read all comments :-) – Rui Jarimba Feb 14 '19 at 07:45
  • Does this answer your question? [Nuget connection attempt failed "Unable to load the service index for source"](https://stackoverflow.com/questions/41185443/nuget-connection-attempt-failed-unable-to-load-the-service-index-for-source) – Jim G. Feb 11 '20 at 17:18
  • 2
    What seemed to help me was using --force on dotnet restore or dotnet publish commands – cah1r Jul 14 '20 at 05:32
  • This is great. What fixed for me was the pipeline settings found here: https://stackoverflow.com/a/61384799/1949132 – deebs Aug 17 '22 at 17:18

8 Answers8

43

For thoses comming here in 2021 for the same error message, adding the NuGetAuthenticate@1 task before the pack command may be the missing piece:

- task: NuGetAuthenticate@1

- task: DotNetCoreCLI@2
  inputs:
    command: 'pack'
    packagesToPack: $(projectPath)
    includesymbols: true
    includesource: true
    versioningScheme: 'off'
    verbosityPack: Normal
  displayName: 'Dotnet Pack'

Update response to use NuGetAuthenticate@1 instead of NuGetAuthenticate@0 in response to reflect Paul Hatcher revision in code.

Jean-Francois Rondeau
  • 1,008
  • 2
  • 13
  • 15
  • 5
    Its now 2022 - this just worked for me! In my case, I had a `dotnet restore` task right before a `publish` task. The restore task successfully pulled from my private artifact feeds and restored the projects without hassle. Before adding this, the publish task was failing with a 401. Any idea why I needed this for the `publish` command and not the `restore` command? I guess the question here is why could I pull but not push to the feed when the build service had `contributor` access to the artifacts feed? – Dom Bavetta Mar 15 '22 at 19:11
  • This did it for me too. I was VERY confused because everything was working fine and then it stopped after I started removing access for a user that had left the company and also the one that had configured our entire Azure DevOps. I can only assume that either a) something changed in DevOps and this is now a requirement or b) he had the authentication for the DevOps artifacts somehow tied to his login! – Ben Thomson Oct 04 '22 at 22:12
  • 1
    Adding the task: NuGetAuthenticate@1 worked for me too – Lybecker Jan 13 '23 at 14:24
  • 1
    I also had to turn off "Limit job authorization scope to current project" in the project's Pipeline Settings. – AyCe Jan 31 '23 at 12:28
18

I found a solution - add the following package source to %appdata%\NuGet\nuget.config:

<add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />

Complete file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="MyFeed" value="https://xxxxxxxxxx.pkgs.visualstudio.com/_packaging/xxxxxxxxxx/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <MyFeed>
      <add key="Username" value="LocalBuildAgent" />
      <add key="ClearTextPassword" value="xxxxxxxxxxx" />
    </MyFeed>
  </packageSourceCredentials>
</configuration>

Also, check Regression in .NET SDK 500: 'dotnet tool install' fails with 401 (Unauthorized) when there is a private feed in NuGet.config #7524. This problem seems to be caused by .NET SDK 2.1.500.

Another workaround would be to uninstall that version:

The issue is not present in .NET Core SDK 2.1.400, e.g. it goes away when .NET Core SDK 2.1.500 is uninstalled, and reappears when SDK 2.1.500 is installed again.

Rui Jarimba
  • 11,166
  • 11
  • 56
  • 86
5

Here are the steps that helped me fix this same issue in Visual Studio when I was trying to build a solution that was using a NuGet package hosted in Azure DevOps.

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

enter image description here

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

enter image description here

  1. Finally rebuild the solution.

Hopefully this fix your issue too!

Vitali Karmanov
  • 157
  • 1
  • 5
  • 2
    It helped me because I changed the password for the corporate account, so I just entered it and all packages was restored – ivanko337 Nov 19 '22 at 12:05
  • 1
    Thanks! Signing in to Visual Studio and rebuilding fixed it for me. (I didn't realise I wasn't signed in on my new PC. Visual Studio 2022, Windows 11). – MGOwen Nov 28 '22 at 22:25
4

I encountered the same issue but for a different reason - not having granted the PAT the appropriate access flags. The Packaging (Create, read, update, and delete feeds and packages) scope is required for the PAT, I had before only set the PAT to have a scope of Build (Artifacts, definitions, requests, queue a build, and updated build properties) having mistaken Artifacts as including private package feeds!

The user experience in VS (both 2015 and 2017) wasn't at all helpful though, both versions repeatedly popping-up the credentials dialog instead of giving more information about what the reason might be (apart from the 401 error response, the clue being in the 'Unauthorized' word though ...).

To summarize the steps to consume a private DevOps package feed -

  • In DevOps create a new PAT having the Packages scope as above
  • In DevOps also get the package source URL from the Connect to feed page under Artifacts > Packages (this is required for the -source parameter for 'nuget sources add')
  • Add the package source (with credentials) to your %APPDATA%\NuGet\NuGet.config using -

    nuget.exe sources add -name {your_package_feed_name} -source https://pkgs.dev.azure.com/{your_org}/_packaging/{your_feed}/nuget/v3/index.json -username PATForPackages -password {the_pat_value_you_got_from_azure_devops}
    

Note: nuget sources add will Base-64 encode the PAT into the packageSourceCredentials Password setting. Also being in your user profile the NuGet.config file is relatively secure provided you keep it secured there, the downside is that this is a host pre-requisite, a consequence of nuget not having in-built Azure DevOps authentication.

jjee
  • 225
  • 1
  • 6
  • Can you screenshot the permissions you needed to add to get this working? Can you perhaps add a shot of where you initially missed the correct permissions? A diff? – Judy007 Feb 18 '21 at 03:36
  • Simple solution and worked perfectly after hours lost on trying to make SET VSS_NUGET_EXTERNAL_FEED_ENDPOINTS={} work, thanks – Jakub Pawlinski Apr 28 '21 at 16:36
3

Using the latest "Use .NET Core sdk 2.1.504" task worked for me. Seems there are some buggy versions of .NET Core sdk 2.1.5xx out there.

Andrel Vahter
  • 101
  • 1
  • 2
  • We are seeing this 401 error with `dotnetcore-sdk:2.1.503` - [must be fixed with 504 as confirmed with this posting](https://github.com/NuGet/Home/issues/7524#issuecomment-463993365). Tried using **Devops Net Core SDK Task** but it didn't work for me with self-hosted agent, but using **Nuget Restore Task** and manually assigning the `nuget.config` worked. Definitely an SDK tooling issue. – SliverNinja - MSFT Apr 04 '19 at 04:23
3

A quick note for anyone who might visit this answer in 2023 - this issue can sometimes be completely intermittent. I had a working pipeline on Friday, but today, Monday it failed with this message.

While perusing this SO page, I happened to notice and correct a completely unrelated code issue (a comment that needed deleting) and checked that in while continuing to read the answers here. Imagine my surprise when on switching back to the build, it had completed.

So one possible answer is: just try running the build again.

Sigh.

Edit: Seems that at the time I had this problem, the service status for Azure Devops - Artefacts was "degraded". So check that before changing your pipeline.

Kit
  • 2,089
  • 1
  • 11
  • 23
  • Returned to this months later with the same issue - and this time, lo and behold, the PAT *had* expired. – Kit Aug 02 '23 at 15:06
2

I had to change the nuget installer to 4.8.1 in order for this to work after switching VSTS url to the new Azure Devops url.

enter image description here

cal5barton
  • 1,606
  • 1
  • 14
  • 29
  • 2
    Unfortunately, this will only work if you are targeting a single `TargetFramework`. If you are using `TargetFrameworks` with more than one, it will cause `dotnet build` to fail when using the `--no-restore` parameter. That said, if you remove the `--no-restore` parameter on `dotnet build` the credentials for Azure Artifacts seem to be cached from `nuget restore` so the restore using `dotnet restore` (or `dotnet build` without `--no-restore`) then functions and restores all of your `TargetFrameworks`. – NightOwl888 Jun 23 '19 at 07:10
  • Thanks @NightOwl888 for sharing this workaround. It worked for me, and I intend to use it. Another reason for the success of this workaround could be that `dotnet restore` obtains the packages from a cache instead of accessing the artifact feed using cached credentials. Just guessing though. I don't actually know why this works. – Tyson Williams Oct 22 '19 at 19:31
  • I think it is because of cached NuGet packages. It is not cached credentials because my logs show that `dotnet restore` is still unable to authenticate. On the other hand, before my program began depending on locally hosted NuGet packages, `dotnet restore` was taking about 72 seconds, but it only takes about 5 seconds when running after `nuget`. Furthermore, `nuget` only takes about 37 seconds, so running both is FASTER by about 40%! – Tyson Williams Oct 22 '19 at 20:02
2

In my case, it was a silly thing: the Azure Devops PAT (personal access token) had expired.

By the way, I recommend specifying only the source in the nuget.config file, and then adding the credentials in this way:

dotnet nuget update source your-source-name -u "tour_user@your.domain" -p "PAT obtained from Azure devops with appropriate packaging permissions"

This adds the credential to a file in your user profile, and machine encoded, so it's quite safe. You shouldn't expose your PAT as clear text.

Remember that PATs expire by default in 1 month, or max, 12 months, if you change the default expiration.

JotaBe
  • 38,030
  • 8
  • 98
  • 117