[source mapping] Having a duplicate source breaks msbuild sdks restore

[jeromelaban]

NuGet Product Used

dotnet.exe, Visual Studio Package Management UI

Product Version

8.0.300

Worked before?

unknown

Impact

Other

Repro Steps & Context

1. Clear all caches: dotnet nuget locals all -c
2. Create a library: dotnet new classlib -o test01
3. Change the test01.csproj sdk to be Sdk="MSTest.Sdk/3.3.1"
4. In %appdata%\NuGet\NuGet.Config. add the following mapping:

<packageSource key="nuget.org">
        <package pattern="System.*" />
</packageSource>

5. In the test01 folder, create a nuget.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="NuGet official package source" value="https://api.nuget.org/v3/index.json" />
    </packageSources>
</configuration>

6. In classlib01, run dotnet restore

Notice that if the custom nuget.config file added in the project folder is removed or the duplicate nuget.org source is removed, the restore succeeds.

Verbose Logs

D:\temp\test01\test01.csproj : error : Could not resolve SDK "MSTest.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
D:\temp\test01\test01.csproj : error :   SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" returned null.
D:\temp\test01\test01.csproj : error :   Unable to resolve 'MSTest.Sdk (= 3.3.1)' for '.NETStandard,Version=v0.0'. PackageSourceMapping is enabled, the following source(s) were not considered: Microsoft Visual Studio Offline Packages, NuGet official package source.
D:\temp\test01\test01.csproj : error MSB4236: The SDK 'MSTest.Sdk' specified could not be found.

[JonDouglas]

/cc @nkolev92 & @donnie-msft related to #13469

[nkolev92]

What would you have expected to happen @jeromelaban compared to what the error message tells you today. (we have ideas ourselves, but don't want to lead you towards those :D )

[jeromelaban]

In itself, the message is does not feel easily actionable. Knowing the cause, I'd intuitively say that it should fail/warn earlier because the source mapping got overridden.

Also, maybe displaying all the known sources would have told that none of the available ones were considered?

[nkolev92]

Today it says:

Unable to resolve 'MSTest.Sdk (= 3.3.1)' for '.NETStandard,Version=v0.0'. PackageSourceMapping is enabled, the following source(s) were not considered: Microsoft Visual Studio Offline Packages, NuGet official package source.

A more powerful message would be to say "no sources" were considered potentially, because the package is not mapped.
Another idea is to warn the duplicate sources as well.

[jeromelaban]

Both messages would help for sure.

Another problem I see here is that the user for unoplatform/uno#16758 (reply in thread) stumbled on this issue had a lot of mappings defined at the user level. It feels like an incorrect use of the source mapping feature, as it forces any new package use to be added to the the mapping list (with errors like #13469). This situation is what led to this particular issue.

[donnie-msft]

had a lot of mappings defined at the user level

I wonder if my rough proposal in #13173 to have NuGet tooling able to create configs that <clear/> (reset) the list of package sources would have prevented creating those at the user-level.
Not the complete solution here, but perhaps a piece of the puzzle.

[Arlodotexe]

I was also hitting this issue, getting errors such as

         V:\Windows\components\Converters\src\CommunityToolkit.WinUI.Converters.csproj : error NU1100: Unable to resolve 'Microsoft.Windows.SDK.NET.Ref (= 10.0.22621.37-preview)' for 'net8.0-windows10.0.22621'. PackageSourceMapping i
       s enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, MainLatest, nuget.org.

and

PS V:\Windows> dotnet tool restore
Package Source Mapping is enabled, but no source found under the specified package ID: uno.check. See the documentation for Package Source Mapping at https://aka.ms/nuget-package-source-mapping for more details.

I managed to work around this issue by modifying my %appdata%\NuGet\NuGet.Config. Either removing the packageSourceMapping or pattern matching a wildcard does the trick.