error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json (in VS .fsx editor or FSI)

[smoothdeveloper]

NuGet Product Used

MSBuild.exe

Product Version

dotnet 8.0.100-rc.2.23502.2

Worked before?

not version specifc

Impact

It's more difficult to complete my work

Repro Steps & Context

I'm facing this when using the #r "nuget: ..." FSI extension in VS or from FsiAnyCpu.exe (and likely in dotnet fsi the same):

error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json

Repro steps

Editing a .fsx script with few #r "nuget: ...", the first one shows squiggles with this error message, which also shows in the VS status bar.

Expected behavior

In case of network error, I think it needs to gracefully attempt package resolution based on ~/.nuget/packages, and report the network issues via telemetry, and fail to the user only if the local resolution failed.

Maybe there is a way to show a warning rather than an error squiggle in such case.

It may still be allowed to fail if it can't resolve dependencies based on the local cache.

Actual behavior

can't load packages in runtime FSI script evaluation or design time script editing in VS and other IDEs.

Known workarounds

• manual package reference from nuget cache (difficult to get right)
• paket FSI extension which seems to be more robust, it resolves from the cache due to reading lock file, and the dependencies are already there

Related information

I never face this with machine in US, but do in Europe.

possibly related issue:

• DNS lookups fail for api.nuget.org using Alpine based dotnet Docker images in AWS us-east-1 NuGetGallery#9396 (comment)
• [NuGet.org Bug]: Unable to load the service index for source NuGetGallery#9699

how nuget is called in this use case:

• https://github.com/dotnet/fsharp/tree/main/src/FSharp.DependencyManager.Nuget
• https://github.com/dotnet/fsharp/blob/main/src/FSharp.DependencyManager.Nuget/FSharp.DependencyManager.fs

@KevinRansom may be able to provide you information about how the msbuild file that has <PackageReference/> tags is generated, and how the extension then loads the resolved assemblies based on this. And there is probably some exchange you could have to enable end users to look at the actual exceptions or print warnings about offline resolution of packages.

Tracking the issue in F# also: dotnet/fsharp#16278

VS 2022 Version 17.7.6

.NET SDK:
 Version:   8.0.100-rc.2.23502.2
 Commit:    0abacfc2b6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100-rc.2.23502.2\

.NET workloads installed:
 [maui-android]
   Installation Source: VS 17.7.34221.43
   Manifest Version:    8.0.0-rc.2.9530/8.0.100-rc.2
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100-rc.2\microsoft.net.sdk.maui\8.0.0-rc.2.9530\WorkloadManifest.json
   Install Type:              Msi

 [android]
   Installation Source: VS 17.7.34221.43
   Manifest Version:    34.0.0-rc.2.479/8.0.100-rc.2
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100-rc.2\microsoft.net.sdk.android\34.0.0-rc.2.479\WorkloadManifest.json
   Install Type:              Msi


Host:
  Version:      8.0.0-rc.2.23479.6
  Architecture: x64
  Commit:       0b25e38ad3

.NET SDKs installed:
  5.0.408 [C:\Program Files\dotnet\sdk]
  6.0.404 [C:\Program Files\dotnet\sdk]
  7.0.102 [C:\Program Files\dotnet\sdk]
  7.0.403 [C:\Program Files\dotnet\sdk]
  8.0.100-preview.7.23376.3 [C:\Program Files\dotnet\sdk]
  8.0.100-rc.2.23502.2 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.7.23375.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-rc.2.23480.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.7.23375.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0-preview.7.23376.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0-rc.2.23479.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Verbose Logs

No response

[jeffkl]

@smoothdeveloper NuGet should only be attempting to contact the configured feeds if the package is not already found in the local package folder. Are you sure all packages were already available before you did a restore?

Also, if any package versions are using wildcards, NuGet will contact the feeds to ensure that a newer version isn't available. Are any of the versions in your package list using something like 1.*?

[smoothdeveloper]

@jeffki thanks for the inquiry, firstly, the issues have been intermittent, last friday, and yesterday somehow it was very bad, but not encountered today.

checking my packages

$ dir fsharp.data.sqlclient
1.2.0  2.0.1  2.0.2  2.0.7  2.1.1  2.1.2

gauth@p14s MINGW64 /C/Users/gauth/.nuget/packages
$ dir csvhelper
12.1.1  2.0.0  2.13.0  2.13.5  2.14.0  2.15.0  2.2.0  26.0.1  30.0.1

gauth@p14s MINGW64 /C/Users/gauth/.nuget/packages
$ dir spectre.console
0.46.0  0.47.0

gauth@p14s MINGW64 /C/Users/gauth/.nuget/packages
$ dir argu
3.2.0  6.1.1

and they don't seem to have had parent folder modified yesterday

So I'm close to certain it wasn't missing package.

Also, if any package versions are using wildcards, NuGet will contact the feeds to ensure that a newer version isn't available. Are any of the versions in your package list using something like 1.*?

CsvHelper and FSharp.Data.SqlClient were fixed, the others not.

It would make sense to complete resolution (while emitting a warning) with the local cache if the host can't be reached, even if there are wildcards; this would make it more resilient without having dire repercussion, compared to script editor tooling or F# interpreter being broken when this condition occurs.

• Is it something that can be improved?
• Is there a way to see logs of the resolution, in a file or event trace?
• is there something the nuget extension that is in F# Interactive (and others, dotnet interactive uses it or similar) could do, to surface more diagnostic to the user?

Thanks!