Home: dotnet restore appears to hang on slow connections

[natemcmaster]

_From @natemcmaster on January 20, 2017 17:33_

Steps to reproduce

Get slow internet.
Clear nuget caches.
dotnet new.
Add dependencies to lots of packages not in the first-run cache warmup. This can be done in a simple app by adding a bunch of rids to <RuntimeIdentifiers>.
dotnet restore.

Expected behavior

Show some sign of progress while downloading from the network. A spinner would be great, but even just confirmation that restore has begun would be helpful.

Actual behavior

No console output appears until NuGet is almost done with the restore. In the screenshot below, restore took over a minute (85 seconds). There was not console output until about 75 seconds after restore began

Environment data

dotnet --info output: using 1.0.0-rc3

cc @shanselman @blackdwarf

_Copied from original issue: dotnet/cli#5406_

[emgarten]

Restore previously solved this by writing out GET messages to let the user know what activity was taking place, however this is now hidden by default which causes users to once again think that NuGet is hung.

Previous issue: https://github.com/dotnet/cli/issues/1623

The logging for dotnet restore is done by an MSBuild task. I don't know if it is possible to create a spinner by logging through the MSBuild logger.

[blackdwarf]

Spinners will not work for CLI scenarios, however ASCII progress bars would. 😄 @natemcmaster do you see enough info if you pass in -v normal?

[shanselman]

@blackdwarf I see spinners all the time. https://github.com/sindresorhus/cli-spinners Or at the least, yes, progress like NPM.

[blackdwarf]

@shanselman that was a joke on my part. But, anyway, the main point is, does changing the verbosity influence this?

[shanselman]

I would have to test again. Point is, under fairly typical networking conditions (this was 3Mbs, consistently) we still saw a LONG pause with no feedback. You gotta show something. ...... dots....something.

[shanselman]

Just checked it @blackdwarf. I have 35Mbs here. Did -v but still waited around for a WHILE with no feedback.

[rrelyea]

can we log a dot, w/ no "n", for each get? or something like that?

[blackdwarf]

The fact that normal verbosity doesn't influence this is pretty bad. @rrelyea back in the day, nuget client used to have a verbosity setting for this. Did we remove that?

In lack of that, I think that _any_ output would be good. We could, I think, do a progress bar? Unless there is some limitation in the MSBuild loggers?

[emgarten]

nuget client used to have a verbosity setting for this. Did we remove that?

The verbosity level is still there. dotnet restore is explicitly calling msbuild /t:Restore with a less verbose level.

A progress bar is difficult because restore downloads/discovers packages as it walks to be as efficient as possible, it doesn't know if there will be zero or a hundred packages downloaded until the end.

Restore should have a great progress experience from the console, I'm just not sure what is possible given the way restore works and the limitations of the MSBuild logger.

[blackdwarf]

@emgarten I see...is there a mapping between restore verbosity levels and MSBuild ones?

OK, so nix the progress bar idea. A series of dots as @rrelyea suggested would be good then I guess?

[emgarten]

Dots could work. In the restore task NuGet knows the msbuild verbosity. It could convert lower level messages that it isn't going to display into dots.

[rrelyea]

feedback from @DoRonMotter

• keep diag output a superset of normal build output...so log parsers don't get confused.
• pushing to 4.0.1 as this doesn't currently meet the bar.

[shanselman]

I'd also point out that "it's hard to do async progress bars" isn't really fair. Docker and npm and Yarn have nice ones.

[ghost]

A docker like progress bar with transmission rate / total size is actually quite useful. Here is a sample code to make a simple spinner https://blogs.msdn.microsoft.com/brada/2005/06/11/showing-progress-in-a-console-windows/.

that or windows 98 drumsticks

[gbaydin]

Hello, I was wondering whether there has been any progress in adding a simple progress bar to dotnet restore. We're currently working on machine learning code (DiffSharp, TorchSharp) that depend on very large nuget packages (some GBs) that hold CUDA binaries, for example the following package and its dependencies:

https://www.nuget.org/packages/libtorch-cuda-10.2/

and the user experience of dotnet restore is not great because it "hangs" for long periods of time (say, half an hour in my average broadband home connection in the UK) without showing any indication of what is going on. Similar workflows in other ecosystems (say, Python pip, conda etc., or Docker) show progress information during package download showing the progress for the file currently being downloaded, download speed, ETA, etc. I think dotnet restore really needs such basic progress information in the CLI out of the box with the default settings.

I don't know if this is the correct project to report this problem (this existing issue seemed relevant). Please let me know if I should be opening an issue somewhere else, for example https://github.com/dotnet/sdk

Also tagging @dsyme @interesaaat

I'm using dotnet CLI tools on linux. This is the output of dotnet --info if it helps:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

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

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

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download