Mysterious new NuGet source (/usr/local/share/dotnet/library-packs)

[dannyyy]

Description

After following the installation guide for MAUI on MacOS I'm unable to restore any regular .NET solution. The installation of MAUI added somewhere hidden a new NuGet source /usr/local/share/dotnet/library-packs which takes precedence over all.

My setup is always the same. I have a NuGet.Config in my home folder /Users/<username>/.nuget/NuGet/ and a NuGet.Config in the root of my repository. They contain one source with the same name, targeting Azure DevOps Artifacts. This exists for years.

• Executing dotnet nuget list source just lists the one source within my own NuGet.Config
• The corresponding source panels in Visual Studio or Rider also just shows this one configured source

The resulting error is:

error NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. The following sources are defined: https://xyz.pkgs.visualstudio.com/_packaging/MyProject/nuget/v3/index.json, /usr/local/share/dotnet/library-packs [/Users/<username>/Development/MyProject/MyProject.sln]

Where is this source configured? And how to get rid of them?

Steps to Reproduce

1. Open any solution in any folder or create a new project with enabled central package management Directory.Packages.props
2. Try to restore
3. Be excited of the error above

Link to public reproduction project repository

Version with bug

6.0.400

Last version that worked well

Unknown/Other

Affected platforms

macOS, I was not able test on other platforms

Affected platform versions

MacOS 12.6

Did you find any workaround?

Not yet

Relevant log output

`dotnet restore`
> error NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. The following sources are defined: https://xyz.pkgs.visualstudio.com/_packaging/MyProject/nuget/v3/index.json, /usr/local/share/dotnet/library-packs [/Users/<username>/Development/MyProject/MyProject.sln]

---

`dotnet worload list`
> Installed Workload Ids      Manifest Version      Installation Source
---------------------------------------------------------------------
wasm-tools                  6.0.10/6.0.400        SDK 6.0.400        
macos                       12.3.465/6.0.400      SDK 6.0.400        
ios                         16.0.517/6.0.400      SDK 6.0.400        
maccatalyst                 15.4.465/6.0.400      SDK 6.0.400        
maui                        6.0.541/6.0.400       SDK 6.0.400        
tvos                        16.0.517/6.0.400      SDK 6.0.400        
android                     32.0.476/6.0.400      SDK 6.0.400  

---

`dotnet nuget list source`
> Registered Sources:
  1.  XYZ [Enabled]
      https://xyz.pkgs.visualstudio.com/_packaging/MyProject/nuget/v3/index.json

[ghost]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[KalleOlaviNiemitalo]

This seems pretty much a duplicate of #27840, which suggests the undocumented DisableImplicitLibraryPacksFolder property as a workaround. The property is checked here:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.NuGetOfflineCache.targets

Lines 27 to 29 in 6a37511

	<PropertyGroup Condition=" '$(DisableImplicitLibraryPacksFolder)' != 'true' ">
	<RestoreAdditionalProjectSources Condition="Exists('$(_WorkloadLibraryPacksFolder)')">$(RestoreAdditionalProjectSources);$(_WorkloadLibraryPacksFolder)</RestoreAdditionalProjectSources>
	</PropertyGroup>

That code was added in #12314 for #11493. At the NuGet side, the problem should have been fixed in NuGet/NuGet.Client#4764 for NuGet/Home#11951, but that fix is not on the release-6.3.x branch, so you may have to wait for the NuGet 6.4 release.