Home: `UserSettingsDirectory` resolves incorrectly for dotnet on Mac

[sandyarmstrong]

Environment

dotnet 2.0.0-preview3-006689
OS X (and presumably Linux)

The Problem

When using NuGet functionality in .NET Core on Mac (and presumably Linux), NuGetFolderPath.UserSettingsDirectory incorrectly resolves to ~/.nuget, causing a different default NuGet.config to be used than Visual Studio for Mac or any non-Core user of Nuget.Client.

Impact

On Windows, users expect to be able to modify their NuGet configuration via their IDE. They can add myget URLs, internal feeds, etc, all in Visual Studio, and those feeds will be available to dotnet. On Mac, users follow that same expectation and then cannot figure out why dotnet is not using the feeds they just configured.

I sincerely hope it's possible to fix this in time for .NET Core 2.0 final.

Explanation

NuGetFolderPath.UserSettingsDirectory is documented to resolve to %APPDATA%\NuGet. On Mac and Linux, using Mono, SpecialFolder.ApplicationData has always followed the freedesktop.org XDG Base Directory Spec, and mapped to the value of XDG_CONFIG_HOME (or ~/.config by default).

So, anyone using NuGet.Client on Mac or Linux would have NuGetFolderPath.UserSettingsDirectory map to ~/.config/NuGet by default. This is depended on by Visual Studio for Mac, among other products.

In fact, Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData returns ~/.config in .NET Core 2.0, just like Mono.

However, in NuGetEnvironment, which had to support earlier versions of .NET Core that lacked the Environment.SpecialFolder APIs, there is a custom implementation to resolve locations like ApplicationData.

For some reason, ApplicationData is made to resolve to ~/.nuget, even though LocalApplicationData is correctly following the XDG spec.

I have to assume this behavior was kept to avoid breaking compatibility with earlier .NET Core releases. But I think that break is necessary to provide consistency with Visual Studio for Mac and other tools.

Other reasons to fix this:

• Consistency with the documentation.
• Consistency with Windows, which has dropped use of ~/.nuget.
• Littering a Linux user's home directory with random dot directories is bad practice. Users should be able to switch their entire desktop's configuration by simply changing the value of XDG_CONFIG_HOME.

This bug was originally filed at https://github.com/dotnet/sdk/issues/1398, but I was asked to move the discussion here.

[sandyarmstrong]

@livarcocc

[sandyarmstrong]

I just tested a new .NET Core 2.0 solution restore on Mac.

Mono 5.2.0.196
dotnet 2.0.0-preview3-006689
VSmac Version 7.1 Preview (7.1 build 1258)

Here are the results:

• dotnet restore
  
  
  
  • uses ~/.nuget
  
  
• dotnet msbuild /t:Restore blah.sln
  
  
  
  • uses ~/.nuget
  
  
• msbuild /t:Restore blah.sln
  
  
  
  • uses ~/.config
  
  
• Visual Studio for Mac right-click solution and Restore NuGet Packages
  
  
  
  • uses ~/.config
  
  

[sandyarmstrong]

Visual Studio 15.3 for Mac shipped today, with .NET Core 2.0 support.

This bug is still not fixed. VS and dotnet use different NuGet.config files.

[gabrieljoelc]

I don't use VS for Mac (I use vim and omnisharp-vim), but I was just trying to use a local nuget package and discovered this mismatch as well between dotnet restore using ~/.nuget and:

• nuget sources add
  
  
  
  • uses ~/.config
  
  

dotnet 2.2.401

I worked around this by manually adding the local source to ~/.nuget/NuGet/NuGet.Config (instead of with nuget sources add), which, as mentioned above, is the path that dotnet restore uses.

[gabrieljoelc]

Can you at least provide a way to set the nuget config path ourselves? something like:

nuget config -ConfigPath ~/.nuget

[mrward]

Related issue #4413 - NuGet writes the NuGet.Config in ~/.config folder, but dotnet restore reads from ~/.nuget

[keith-miller]

Hmm, two and a half years, still happening. It makes using Net Core in linux based CI/CD systems a pain. Any updates?