Home: dotnet restore does not use NuGetDefaults.Config on Linux

[livarcocc]

_From @kpstolk on February 28, 2019 17:52_

According to the NuGet documentation it is possible to store a NuGetDefaults.Config file in ~/.local/share or /usr/local/share to configure global settings.

We currently use a Windows machine and using this file (on %ProgramFiles(x86)%\NuGet\Config of course) works just fine with dotnet restore.

However now I'm setting up an Ubuntu 18.04 build server and have installed dotnet but the NuGetDefaults.Config doesn't seem to be used as I get an error from dotnet restore.

I also tried to install NuGet directly using sudo apt-get install nuget but this doesn't work either with nuget restore, I get the same error. It does work however when I store the file in ~/.config/NuGet/NuGet.Config (so not at Computer but User level).
Even configured at user level dotnet restore still fails.

So how else can I configure my custom package source?

Steps to reproduce

1. Install .NET Core SDK on Linux Ubuntu 18.04 x64
2. Create a NuGetDefaults.Config in both ~/.local/share or /usr/local/share with content as shown below
3. Clone Git repo containing .NET Core project and cd to it
4. Run dotnet restore
5. Error NU1101 is shown

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <packageSources>
        <add key="MySource" value="http://my/custom/source/" />
    </packageSources>
</configuration>

Expected behavior

dotnet restore to restore packages from my custom package source defined in NuGetDefaults.Config.

Actual behavior

Error from dotnet restore:

/home/user/devops/_work/1/s/src/path/to/my.csproj : error NU1101: Unable to find package My.Custom.Package. No packages exist with this id in source(s): nuget.org

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.104
 Commit:    73f036d4ac

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.2.104/

Host (useful for support):
  Version: 2.2.2
  Commit:  a4fd7b2c84

.NET Core SDKs installed:
  2.2.104 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

_Copied from original issue: dotnet/cli#10897_

[livarcocc]

_From @kpstolk on February 28, 2019 17:56_

This issue seems related regarding the (lack of) documentation of dotnet restore.

[octocat-mona]

@livarcocc It is a NuGet issue, not related to how dotnet uses / integrates with NuGet?

[livarcocc]

even if it is about dotnet, the code for NuGet inside dotnet is also owned by NuGet, which is why I moved the issue here.

[octocat-mona]

@livarcocc I was wondering already how dotnet embeds NuGet and with what version etc, is that documented somewhere?

[rrelyea]

nuget release notes (at least current ones) are starting to show which version of .net core sdk has that version in it.
See NuGet 4.9 release notes for example.

But the way that will always work is to go into the specific sdk version and look at nuget.*.dll files for version info.
powershell is a good way to do this: link to stackoverflow technique

cd C:Program Filesdotnetsdk2.1.504
[System.Reflection.Assembly]::LoadFrom("nuget.build.tasks.dll").GetName().Version
Returns:
Major Minor Build Revision

---

4 9 3 0

[octocat-mona]

Thanks @rrelyea , that clarifies a lot!
So this bug (if it appears to be a bug at least) is in in the latest recommended NuGet version 4.9.3.

I just noticed that dotnet nuget also shows the NuGet version, didn't notice that command before.

[eltiare]

This is a major pain point for anyone who has more than one feed to deal with and works from the command line.

[carlowahlstedt]

I confirm seeing this issue on macOS.

dotnet restore doesn't restore from a privately authenticated feed
nuget restore does restore from a privately authenticated feed

I initially setup the feed in VS for Mac but don't see it in ~/.nuget/NuGet/Nuget.Config. However, running nuget sources does list the privately setup feed AND running dotnet restore does attempt to use the feed, but it doesn't properly authenticate like nuget restore does:

I did also find on stackoverflow that nuget uses msbuild via mono, which I can confirm seeing (and thus I assume, without the details, why it is working):

Additionally, I did run nuget update -self command successful so that dotnet is using 4.9.4 instead of 4.8.2:

Confirm nuget version:

Confirm dotnet nuget version:

EDIT:
ok...didn't realize the solution I was testing dotnet restore with had a location nuget.config file. After removing that, it seems to reference the ~/.nuget/NuGet/Nuget.Config file because if I manually edit that file to include the package source, then I see the same 401 error as above.

[arthis]

Issue is still here.

Nuget restore calls $HOME/.config/NuGet/NuGet.Config
dotnet restore calls $HOME/.nuget/NuGet/NuGet.Config

I have the following NuGet.Config file :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="Store" value="https://My tfs 2017 connection goes here" />
  </packageSources>
  <packageSourceCredentials>
    <Store>
        <add key="Username" value="vsts" />
        <add key="ClearTextPassword" value="xxxxxxxxxxxxxx" />
      </Store>
  </packageSourceCredentials>
</configuration>

When calling nuget restore on my csproj with dependencies in the tFS store , and with nuget version 5.2, everything is ok.
Doing the same with up to the latest preview of dotnet available at the moment (dotnet-sdk-3.0.100-preview5-011568-linux-x64), I have embedded the version 5.1 for nuget components. Calling dotnet restore with the NuGet.Config forementionned results in :

john@MyMachine:~/dotnet$ dotnet --version
3.0.100-preview5-011568
john@MyMachine:~/dotnet$ dotnet restore /pathTo/myProjectWithTfsDependencies.csproj
/home/john/dotnet/sdk/3.0.100-preview5-011568/NuGet.targets(121,5): error : Unable to load the service index for source "https://My tfs 2017 connection goes here". [/pathTo/myProjectWithTfsDependencies.csproj]
/home/john/dotnet/sdk/3.0.100-preview5-011568/NuGet.targets(121,5): error :   GSSAPI operation failed with error - An invalid name was supplied (Configuration file does not specify default realm). [/pathTo/myProjectWithTfsDependencies.csproj]

When will Nuget 5.2 version be included in dotnet core sdk ?

[aortiz-msft]

https://github.com/NuGet/Home/issues/7980 closed as dupe of this issue.

[beppler]

Running dotnet nuget resulted in NuGet Command Line 5.6.0.5.

Looking at the sources of the configuration reader on NuGetEnvironment line 41 and NuGetEnvironment line 36 and NuGetEnvironment line 126 it appears that the documentation is wrong for the directory where NuGetDefaults.config is stored.

The right location is /etc/opt/NuGet. Also as linux use a case-sensitive filesystem the file name must be NuGetDefaults.config (not NuGetDefaults.Config).

[eruizc-dev]

This is my experience in Manajaro Linux with dotnet restore and dotnet version 3.1.108

Read:

• ./nuget.config
• ~/nuget.config
• ~/.nuget/NuGet/NuGet.Config

Not read:

• ~/.nuget/NuGet/nuget.config
• ~/.nuget/nuget.config
• ~/.config/Nuget/nuget.config
• ~/.config/Nuget/NuGet.Config