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 · 11 comments
Area:Settings NuGet.Config and related issues Platform:Xplat Priority:2 Product:NuGet.exe NuGet.exe Type:DCR Design Change Request


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

Copy link

@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

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?

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.

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
Copy link

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

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.

Copy link

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.

Copy link

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?

Copy link

sandyarmstrong commented Aug 29, 2019

@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 heng-liu self-assigned this Nov 20, 2020
omajid added a commit to omajid/dotnet-docs that referenced this issue Sep 29, 2021
`dotnet nuget` uses this location, `mono`/`nuget` use the other
location: NuGet/Home#4413

See: NuGet/Home#10185
tdykstra pushed a commit to dotnet/docs that referenced this issue Sep 30, 2021
`dotnet nuget` uses this location, `mono`/`nuget` use the other
location: NuGet/Home#4413

See: NuGet/Home#10185
@aortiz-msft aortiz-msft added the Type:DCR Design Change Request label Feb 2, 2022
Copy link

We end up with updating docs in NuGet/
Please refer to the spec for more details.
Close as fixed.

Copy link

Documenting a poor workaround is not a "fix"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Area:Settings NuGet.Config and related issues Platform:Xplat Priority:2 Product:NuGet.exe NuGet.exe Type:DCR Design Change Request
None yet

No branches or pull requests