Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Iankodj opened this Issue Jan 27, 2017 · 6 comments


None yet
7 participants
Copy link

Iankodj commented Jan 27, 2017

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


This comment has been minimized.

Copy link

zhili1208 commented Jan 27, 2017

@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


This comment has been minimized.

Copy link

mrward commented Jan 28, 2017

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?


This comment has been minimized.

Copy link

Iankodj commented Jan 30, 2017

@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.


This comment has been minimized.

Copy link

sartan commented Aug 8, 2017

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

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

@rrelyea rrelyea modified the milestones: Backlog, Future-0 Aug 15, 2017


This comment has been minimized.

Copy link

siberianguy commented Apr 7, 2018

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


This comment has been minimized.

Copy link

fundead commented May 27, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.