List disabled feeds in restore output

[livarcocc]

From @billwert on April 17, 2017 0:10

See comment below. The repro is the same but now I understand better the cause.

---

This might be related to #6336, but looked sufficiently different I thought I'd open another issue. For example, mine does not fail in the initial restore.

Steps to reproduce

dotnet new console
add RuntimeFrameworkVersion to project:

<RuntimeFrameworkVersion>2.0.0-preview1-002011-00</RuntimeFrameworkVersion>

dotnet restore

Expected behavior

restore succeeds

Actual behavior

Restoring packages for C:\source\t\t.csproj...
C:\dotnets\2.0.0-preview1-005797\sdk\2.0.0-preview1-005797\NuGet.targets(97,5): error : Unable to resolve 'Microsoft.NETCore.App (>= 2.0.0-preview1-002011-00)' for '.NETCoreApp,Version=v2.0'. [C:\source\t\t.csproj]
Generating MSBuild file C:\source\t\obj\t.csproj.nuget.g.props.
Generating MSBuild file C:\source\t\obj\t.csproj.nuget.g.targets.
Writing lock file to disk. Path: C:\source\t\obj\project.assets.json
Restore failed in 88.17 ms for C:\source\t\t.csproj.

Errors in C:\source\t\t.csproj
Unable to resolve 'Microsoft.NETCore.App (>= 2.0.0-preview1-002011-00)' for '.NETCoreApp,Version=v2.0'.

NuGet Config files used:
C:\source\t\NuGet.Config
C:\Users\billw\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

Feeds used:
https://api.nuget.org/v3/index.json
https://www.myget.org/F/aspnetrelease/api/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Environment data

dotnet --info output:
.NET Command Line Tools (2.0.0-preview1-005797)

Product Information:
Version: 2.0.0-preview1-005797
Commit SHA-1 hash: 645bb43291

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\dotnets\2.0.0-preview1-005797\sdk\2.0.0-preview1-005797\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0-preview1-001978-00

Build : d197c00dc0f5ca41ac61b6321ebb37d39b63cf80

Copied from original issue: dotnet/cli#6337

[livarcocc]

From @techyian on April 17, 2017 12:10

The latest version of Microsoft.NETCore.App on Myget as of now is 2.0.0-preview1-002013-00. Just tested with a new console app and it restores correctly. Could you try with that version in your .csproj?

[livarcocc]

From @billwert on April 17, 2017 17:27

Thanks, @techyian. I tried that last night as well and it didn't work.

It appears that the CLI is ignoring feeds with the name dotnet-core. If I change the name in the local Nuget.config to dotnet-core2 it works properly.

C:\source\t>dotnet restore

  Restoring packages for C:\source\t\t.csproj...
  Installing Microsoft.NETCore.DotNetAppHost 2.0.0-preview1-002013-00.
  Installing Microsoft.Packaging.Tools 1.0.0-preview1-25214-01.
  Installing Microsoft.NETCore.DotNetHostResolver 2.0.0-preview1-002013-00.
  Installing NETStandard.Library 2.0.0-preview1-25214-01.
  Installing Microsoft.NETCore.DotNetHostPolicy 2.0.0-preview1-002013-00.
  Installing Microsoft.NETCore.Platforms 2.0.0-preview1-25214-03.
  Installing Microsoft.NETCore.App 2.0.0-preview1-002013-00.
  Generating MSBuild file C:\source\t\obj\t.csproj.nuget.g.props.
  Generating MSBuild file C:\source\t\obj\t.csproj.nuget.g.targets.
  Writing lock file to disk. Path: C:\source\t\obj\project.assets.json
  Restore completed in 4.84 sec for C:\source\t\t.csproj.

  NuGet Config files used:
      C:\source\t\NuGet.Config
      C:\Users\billw\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
      c:\source
      https://api.nuget.org/v3/index.json
      https://www.myget.org/F/aspnetrelease/api/v3/index.json
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

  Installed:
      7 package(s) to C:\source\t\t.csproj

This seems to be the actual bug. I'll re-title this.

[billwert]

Ah the second.

Somehow my global nuget.config has this:

C:\source\t2>type C:\Users\billw\AppData\Roaming\NuGet\NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="dotnet-core" value="https://dotnet.myget.org/f/dotnet-core/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="aspnetrelease" value="https://www.myget.org/F/aspnetrelease/api/v3/index.json" />
  </packageSources>
  <disabledPackageSources>
    <add key="dotnet-core" value="true" />
  </disabledPackageSources>
  <fallbackPackageFolders>
    <add key="CliFallbackFolder" value="C:\Users\billw\.dotnet\NuGetFallbackFolder" />
  </fallbackPackageFolders>
</configuration>

I have no idea how that got there. I did recently install VS2017 community on this machine but I'd be shocked if that just did this.

I'll setup a clean machine and see what I get.

[billwert]

Regardless of how this turns out, it seems like the CLI/nuget.exe should print disabled feeds and note that they are disabled. I'd have gotten there a lot faster if the tools had helped me.

[emgarten]

@billwert glad you were able to track it down. Let me know if you see this feed being disabled automatically. I would expect that this doesn't happen unless you open the Visual Studio NuGet UI and disable the feed yourself.

Running nuget.exe sources will print out the full list of enabled/disabled sources.

[billwert]

Okay, a clean machine doesn't have the bad behavior. It's likely this is left over from last summer or so when I was doing some experimentation at home.

It's good that nuget.exe sources helps out. I'd love to see CLI also do so. I believe the output from dotnet restore is actually out of the Nuget library, correct? If so, would it be possible to make it look like this?

 Feeds used:
      https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
      (disabled) https://www.myget.org/F/aspnetvnext/api/v3/index.json
      https://api.nuget.org/v3/index.json
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

That way the user knows they need to go dig through their config files to figure it out opposed to wondering why it isn't working. The error you get now is not helpful.

(I also wonder about whether or not a local nuget.config should always win over a more global nuget.config..)

[emgarten]

Overriding at the global level with a disabled source is confusing. For this reason it is usually a good idea to clear disabled sources if you know they are needed such as in a git repo.

Here is what nuget has: https://github.com/NuGet/NuGet.Client/blob/dev/NuGet.Config#L11-L13

Your suggestion on marking a feed as disabled in the restore output is part of why the list of config files used is displayed. The user should see the list of enabled feeds, if they were expecting something else they should check the config files to see why it wasn't enable. That has been the current thinking on it anyways.

[billwert]

I think the challenge with the current thinking is that it requires the end user to understand a lot of nuget details. I didn't know you could disable a feed like this, for example, because I use Nuget in a very straightforward way: I add feeds when some project tells me to. Further, because my local Nuget.Config seemed to have what I wanted, it was a few turns of the crank before I even noticed the feed missing from the output. (It "looked alright" in that it had roughly the right number of lines.) If there had been some other marker in the output, it wouldn't have passed the eye test and I'd have known to search the web for 'nuget feed disabled' a lot faster.

Should I open another issue to ask for this feature? It seems like we can probably just use this one but I'm not sure what the work flow is.

[emgarten]

I'll update the title on this one, we can track it here 😄

[mishra14]

Closing this as "Wont Fix". You can use NuGet.exe sources command to list all sources, including the disabled ones. In future we might add a dotnet nuget sources command as well.