Does it work if you just run dotnet restore on a project? Could you try that and let us know what happens.

Alternatively, if this is a VSTS feed, can you run dotnet restore --interactive to authorize the feed and then try to tool install?

From @hrumhurum on November 17, 2018 10:6

dotnet restore results in a similar error:

Restoring packages for C:\Temp\Repro\ContosoConsumer\ContosoConsumer\ContosoConsumer.csproj...
Retrying 'FindPackagesByIdAsyncCore' for source 'https://rd.contoso.com:12345/nuget/feed/FindPackagesById()?id='contoso.foobar'&semVerLevel=2.0.0'.
Response status code does not indicate success: 401 (Unauthorized).
C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : Failed to retrieve information about 'Contoso.FooBar' from remote source 'https://rd.contoso.com:12345/nuget/feed/FindPackagesById()?id='contoso.foobar'&semVerLevel=2.0.0'. [C:\Temp\Repro\ContosoConsumer\ContosoConsumer.sln]
C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Temp\Repro\ContosoConsumer\ContosoConsumer.sln]

https://rd.contoso.com:12345/nuget/feed is not a VSTS feed. It's a NuGet.Server proxied behind an IIS with HTTP basic/digest authentication turned on.

Trying to run dotnet restore --interactive does not make any difference.

From @hrumhurum on November 17, 2018 10:40

A small ready-to-use reproduction sample that shows the error with an existing authenticated MyGet feed:

NuGetAuthRepro.zip

The repro is real and self-sufficient. Just launch the Run.bat file.

It does not work with .NET SDK 2.1.500.
It does work with .NET SDK 2.1.400.

P.S. You may need to invoke dotnet nuget locals http-cache --clear to remove cached HTTP responses when switching from .NET SDK 2.1.400 to .NET SDK 2.1.500 in order to reproduce the issue again, as the auth error may not manifest itself under .NET SDK 2.1.500 when some requests were cached by .NET SDK 2.1.400.

This seems to be the same issue from #7517. @hrumhurum can you try not using spaces in the source name and see if that fixes it? Note that the credentials element should match the source name so you might have to edit that one as well...

@PatoBeltran Removing spaces from the source name does not affect the outcome. The issue still persists.

Try updating the nuget.config to something like:

<?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="Contoso" value="https://rd.contoso.com:12345/nuget/feed" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
  <packageManagement>
    <add key="format" value="0" />
    <add key="disabled" value="False" />
  </packageManagement>
  <packageSourceCredentials>
    <Contoso>
      <add key="Username" value="tester" />
      <add key="Password" value="..." />
    </Contoso>
  </packageSourceCredentials>
</configuration>

This seems to be the same issue from #7517. @hrumhurum can you try not using spaces in the source name and see if that fixes it? Note that the credentials element should match the source name so you might have to edit that one as well...

I was having this issue and removing the space from the source name did fix it. It seemed that using a clear text password kind of fixed it (still failed for custom packages output folder), but no space in the name and it works well now.

@PatoBeltran I followed with the template you have provided. In that case, it does work fine.

The pitfall is this: not only the space character causes the issue, but any other special character like '&' does.

Please find enclosed a ready to use reproduction sample that shows both ' ' and '&' characters causing the problem:
NuGetAuthRepro2.zip

@hrumhurum Your repro solution confirms that the issue is duplicate of #7517.

With that I mean, the fix for #7517 will cover all special characters.

Please follow that one for updates.

I was having this issue as well when trying to use the dotnet restore task on Azure DevOps, using a private build agent. My %appdata%\NuGet\nuget.config looks like this:

<?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 added the Microsoft Visual Studio Offline Packages package source and everything seems to work fine now.

<?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>

Please note that I didn't remove the .NET SDK 2.1.500 from the build agent.

We use the .NET Core SDK 2.2.102 (via the ".NET Core Tool Installer" TFS build task) and .NET restore still fails with the same error. Our private feed has dot in its name like "Foo.Bar".
Is the fix already in the SDK? If yes it doesn't seem to be fixed. If not, when will the fix hit the SDK?

I was having this issue as well when trying to use the dotnet restore task on Azure DevOps, using a private build agent. My %appdata%\NuGet\nuget.config looks like this:

<?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 added the Microsoft Visual Studio Offline Packages package source and everything seems to work fine now.

<?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>

Please note that I didn't remove the .NET SDK 2.1.500 from the build agent.

In the end what worked for me was

1. Adding add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages" to NuGet config
2. Start using newest .NET SDK 2.1.504 , seems 500 -> 503 may have this problem.

I am not sure if there is supposed to be something in C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\, but for me, nothing. In fact, I don't appear to have NuGetPackages on my system, however, I don't use VisualStudio.

From the command line, dotnet build fails as it's looking in one of my private repos, hosted on VSTS that has no bearing on the project I am trying to compile, so why should it even be trying to look in there? Even if it does attempt to look, it should realise it can't access it and just move on. Not throw a terminating error.

My temporary fix - which will break other things, was to comment out the references to my private feeds in $env:appdata\Nuget\NuGet.Config

I am using .Net SDK 5.0.0 and don't have .Net SDK 2.1.500 installed.