Open smoothdeveloper opened 1 year ago
jeffkl
commented
1 year ago @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
commented
1 year ago @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.1and 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.
Thanks!
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 fromFsiAnyCpu.exe(and likely indotnet fsithe same):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
Related information
I never face this with machine in US, but do in Europe.
possibly related issue:
how nuget is called in this use case:
@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: https://github.com/dotnet/fsharp/issues/16278
VS 2022 Version 17.7.6
Verbose Logs
No response