Home: Unable to install or update NuGet package if one package source is failing

Created on 9 Sep 2016  路  3Comments  路  Source: NuGet/Home

With NuGet v3 If one package source is invalid or is failing then it is not possible to install or update a NuGet package when all package sources are being used. With NuGet v2 it is possible to install or update a NuGet package if one package source is failing.

I believe that the NuGet v3 behaviour is by design but wanted to confirm it.

A simple way to reproduce this is in Visual Studio:

  1. Enable only the main nuget.org package source.
  2. Add an invalid package source (e.g. https://www.nuget.org/invalid) and enable it.
  3. In the Package Manager Console select All as the package source.
  4. Install a NuGet package that is not available from the local machine cache.
  5. Try to update an old NuGet package to a later version.

With NuGet v2 in Visual Studio 2013 both 4 and 5 work and it looks like the working package source is used.

With NuGet v3 both 4 and 5 fail. On installing or updating you see an error similar to:

install-package : An error occurred while retrieving package metadata for 'nunit' from source 'invalid'.
  The V2 feed at 'https://www.nuget.org/invalid/FindPackagesById()?id='nunit'' returned an unexpected status code '404 Not Found'.
ByDesign

Most helpful comment

We are building a feature in 3.6 to detect this scenario and prompt the user to disable the source for the session (while explaining the potential side effects), and also detected particularly slow sources and offer the same behavior.

So by now NuGet is in version 4.5, and this is still a constant issue. This seems like a case of letting the perfect be the enemy of the good.

What's wrong with just popping up a dialog and saying "Hey, your sources A, B, and C are available, but X, Y, and Z are offline. Do you still want to install/update/whatever this package? [Yes] [No]"

All 3 comments

Yes this is by design. The problem here is that if one source is temporary off, you will get different results from if it was on because packages on that feed may have more applicable dependencies.

In project.json this could trigger invalid restores as well.

We are building a feature in 3.6 to detect this scenario and prompt the user to disable the source for the session (while explaining the potential side effects), and also detected particularly slow sources and offer the same behavior.

Here is the spec https://github.com/NuGet/Home/wiki/Package-Sources-Diagnostics (not yet fully fleshed out), feel free to comment and help enhance the spec.

We are building a feature in 3.6 to detect this scenario and prompt the user to disable the source for the session (while explaining the potential side effects), and also detected particularly slow sources and offer the same behavior.

So by now NuGet is in version 4.5, and this is still a constant issue. This seems like a case of letting the perfect be the enemy of the good.

What's wrong with just popping up a dialog and saying "Hey, your sources A, B, and C are available, but X, Y, and Z are offline. Do you still want to install/update/whatever this package? [Yes] [No]"

Was this page helpful?
0 / 5 - 0 ratings