[MacOS, Linux] NuGet writes the NuGet.Config in ~/.config folder, but dotnet restore reads from ~/.nuget

[Iankodj]

When using NuGet to add a private feed, NuGet Sources Add writes in ~/.config/NuGet/NuGet.Config file. But when using dotnet restore the ~/.nuget/NuGet/NuGet.Config file is used to read the packageSources and packageSourceCredentials.

This issue forces users to manually copy and paste all necessary information instead of having that generated automatically by the NuGet CLI.

DotNetCore repo issue: dotnet/core#453

[zhili1208]

@rrelyea this is a known issue. It's a dupe of #4095
the problem here is ~/.config is defined by mono not us, we use .net framework Environment variable Appdata Folder for ,net framework(mono) and use ~/.nuget for .net core(this is defined in nuget).

we can't change mono to /.nuget, it will break mono restore for existing user.

My suggestion is not use mono and dotnet at the same time or use -configfile as a workaround.
mono nuget.exe sources add -configfile ~/.nuget/NuGet/NuGet.config

[mrward]

So on Windows dotnet.exe and NuGet.exe both use AppData for their NuGet.Config files but on non-Windows platform they use different locations?

[Iankodj]

@zhili1208 Thanks for the info.

@mrward As far as I understand it is Mono that sets up the AppData variable with the ~/.config path. And dotnet CLI uses directly the ~/.nuget folder.

[sartan]

For the time being, this inelegant workaround seems to do the trick:

ln -s ~/.nuget/NuGet ~/.config/Nuget

[siberianguy]

Have the same problem in Jetbrains Rider (I suppose it's because they use both Mono and .net core). It was weird as the UI showed packages from private repositories but then did not install them. The symlink solution did not help as it blew up Rider (he was saying something about relative paths), so for now I fixed it with a Nuget.config in project's folder

[fundead]

This is a footgun in userland i.e with the use case of needing to run nuget setApiKey (on MacOS in our case), as dotnet nuget doesn't currently have the setApiKey capability. I imagine many machines will get in this state due to installing tools like Rider above and Visual Studio for Mac alongside .NET Core. Would be awesome to see a consistent, non-surprising cross platform experience here.

[theladyjaye]

On a Mac it looks like Visual Studio Mac prefers to read from ~/.config/ I guess that's it's Mono Roots and dotnet wants to read from ~/.nuget/ Is this still the case in Visual Studio Mac 2019?

Additionally, invoking the CLI nuget sources <operation> seems to affect ~/.config/ not ~/.nuget

I just need to figure out what to tell my devs to set. The Symbolic Link solution above is a nice one and I will probably go with that. I just want to be able to be able to note if it's changing in the future.

[Rast1234]

Maybe it will help someone like me: when building my apps in Microsoft's docker container with SDK, i found out that dotnet restore reads these configs:

• /nuget.config - yes, in the root of the filesystem! why?
• /root/.nuget/NuGet/NuGet.Config which is sane but is not present until you run restore the first time.

It would be much easier to just specify an environment variable for all CLI tools. You know, like with all other linux-friendly tooling?

[sandyarmstrong]

@aventurella this is not just a Mono thing. .NET Core also resolves Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData to ~/.config (on Mac and Linux).

It's just that NuGet for .NET Core has this old hard-coded logic in it to look for NuGet.config somewhere else. It used to have this same bad behavior on Windows, and eventually fixed it, but only on Windows.

This is all documented in #5555 , which has been ignored for over 2 years now.

And yes, Visual Studio for Mac 2019 has the same (better) behavior of looking in ~/.config.

[heng-liu]

We end up with updating docs in NuGet/docs.microsoft.com-nuget#2822.
Please refer to the spec https://github.com/NuGet/Home/blob/dev/designs/Consolidate-NuGetConfig_OnLinux.md for more details.
Close as fixed.

[bigjonroberts]

Documenting a poor workaround is not a "fix"