Home: `dotnet restore` fails on authenticated source when user-level config also has source

[zarenner]

dotnet restore doesn't send any credentials if a user-level nuget.config has the same source as a project-level config, and the credentials are specified in the project-level config but not in the user-level config. NuGet.exe does not appear to have this bug.

Apologies if this is a dupe, but there are so many nuget/dotnet auth issues to look through, and it wasn't obvious if there was an exact match.

Repro

1. Create a .NET Core project that requires packages from an authenticated source
2. Create a nuget.config next to the project that has the source, and the source credentials.
3. Create or modify the user-level (perhaps other locations in the chain too) nuget.config to also have the source, but not the credentials. The name doesn't appear to matter, just that the identical URL exists as a source.
4. Run "dotnet restore". It fails with "Unable to load the service index for source" / 401. Looking at the HTTP requests, no authorization header is ever sent.
5. Run "nuget restore ". It succeeds.

Example Configs

Project-level nuget.config

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

User-level nuget.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="test" value="https://<redacted>.pkgs.visualstudio.com/_packaging/test/nuget/v3/index.json" />
  </packageSources>
</configuration>

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): dotnet

NuGet version (x.x.x.xxx): 4.8.0.6 (as reported by dotnet nuget --version)

dotnet.exe --version (if appropriate): 2.1.400

OS version (i.e. win10 v1607 (14393.321)): Windows Server 2016

[nkolev92]

@zarenner Probably a duplicate of this.

https://github.com/NuGet/Home/issues/3580

You mentioned that it works with nuget.exe but not with dotnet.exe?

Those specific code paths should be united normally.

//cc @PatoBeltran
This might be related to how the configs are merged, but I have not investigated.

//cc @rrelyea for visibility.

[phillip-haydon]

ETA on this being fixed?

[PatoBeltran]

This has been solved as part of the latest rework on the nuget.configuration code paths.

[KarinBerg]

Short question: is that bugfix already released because I still have the problem if I try to consume a NuGet package from a private VSTS source

[rrelyea]

This was likely fixed in 4.9.0
However, if it missed that train, it definitely should be in 5.0.0-preview2.