search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 253 forks source link

Deal with slow/misbehaving sources #1627

Open yishaigalatzer opened 9 years ago

yishaigalatzer commented 9 years ago

Today slow sources or defective source interfere with download & search speed.

This is to suggest a mechanism that identifies such sources and provides prompts to the user, and suggests improvements if possible

Here are the few cases that we see today that I would like to address

  1. Server than never responds (timeouts)
  2. Server that returns 5xx results regularly
  3. Server that 404s on the initial calls (initial metadata or index.json)
  4. Slow UNC share
  5. Flat package source with many packages

The suggestion is to detect these as part of normal operations (search, restore, install update), and provide a suggestive UI that allows/suggest to do the following things

  1. Disable or update the URL for defective sources
  2. Suggests changing the folder structure in a flat package source to the hierarchical structure, as describes in this blog
  3. Suggests moving to api.nuget.org/v3/index.json from www.nuget.org/api/v2, and similarly for other known servers that support both V2 and V3

A user should be able to suppress this warnings, so it does not become an annoyance.

yishaigalatzer commented 8 years ago

Also cover the scenario spelled out in https://github.com/NuGet/Home/issues/1627 (recommend moving from V2 to V3). https://github.com/NuGet/Home/issues/1627

yishaigalatzer commented 8 years ago

See #2598 we should enable installing and updating with failed sources after showing a good warning and a way to fix the issue (disable the source or fix the URL, or fix the accessibility)

rrelyea commented 8 years ago

Note...see #2685 -- if the user doesn't authenticate after 3 tries (via cancel, or typing badly), treat that source as misbehaving.

rlundy commented 7 years ago

I came here from #3234 hoping something is being done about the "AggregateException" message I get constantly.

I wonder if part of the problem is a lack of a clear scenario that doesn't have a good workaround.

So here's one: I have the standard nuget.org package source as well as several package sources from my company, which are only available when I'm connected to our VPN.

The fact that NuGet complains when a single package source isn't available means that even if I'm just doing a quick hobby project or proof-of-concept on my work laptop, if I need a single NuGet package, I either have to (a) connect to our VPN (with 2FA, an annoying process) or (b) uncheck those package sources, then remember to recheck them later. Those are the workarounds; neither one is pleasant, and both seem unnecessary.

It would be a much nicer user experience if instead I got a simple popup along the lines of:

"These package sources are not available:

Using package from this source:

Continue? [Yes/No]"

It's especially irksome because in the NuGet tab I can have nuget.org (rather than "All") selected as my package source, but it still trips up over a different unavailable package source that I have no interest in using.

donnie-msft commented 5 years ago

I just ran into an issue using PMUI, clicking Install, and getting no reaction from the UI at all. I looked in the output window (hidden in the background) and saw this:

Restoring packages for C:\myRepo\myProj.csproj...
The local source 'C:\myPackageSource\' doesn't exist.

This is despite the fact I had "nuget.org" selected as the Package source in PMUI, which is confusing.

The fact that we check for dependencies on all sources is, from what I understand, an old design decision the early days of NuGet. We should reevaluate if that still makes sense. At a minimum, PMUI should give some reaction with useful information in the situation I encountered.

//cc: @karann-msft //cc: @rrelyea

rrelyea commented 4 years ago

May be related to #2472