Home: Can't update package when some packages can't be restored

[GeertvanHorrik]

We have an app that uses some (outdated, deleted) packages. I want to update them to the latest version (we automatically clean up prerelease packages older than 25 builds when using prerelease versions).

However, the update fails because before updating, NuGet tries to restore the packages (not sure why) and fails in doing so.

This results in a catch 22, I cannot restore because packages are deleted, but I cannot update because packages need to be restored first.

I think the package restore before updating can be disabled / become optional?

[Seeker1437]

Hi I am not a Nuget person but I did want to say I had something similar myself, I ended up completely uninstalled the packages and reinstalling them with the updated versions.

I know that can be a hassle, but once it's done it should give you the breathing room you need again.

[GeertvanHorrik]

@Seeker1437 Thanks for the workaround, much appreciated!

[rrelyea]

Generally, on Nuget.org at least, we never delete packages -- but instead unlist them.
Doing something similar with your package sources would prevent this kind of situation, right?

[GeertvanHorrik]

What you are suggesting doesn't fix the actual issue. There is absolutely no (technical) need to restore any packages when updating.

Unlisting wouldn't help. For example, on private feeds you are on a specific plan (x gb), MyGet automatically purges older packages for use.

[emgarten]

There is absolutely no (technical) need to restore any packages when updating.

Package dependency information is stored in the nuspecs. When a package update happens NuGet checks for dependency constraints within the existing packages to see if the new package is valid/allowed. For this reason packages need to be restored first so that all constraints can be verified.

Here's an example, say a project has two packages A and B. A contains a dependency on B =1.0.0.
While updating B from 1.0.0 to 2.0.0 the feed A is contained in goes down and the package cannot be found. Updating from B to 2.0.0 would be invalid for A, but there's no way to know that without having A since packages.config doesn't contain this metadata.

It may help to use the -Force flag with Uninstall-Package to clear out the missing packages.

[GeertvanHorrik]

@emgarten The current versions of packages is stored in separate files, right? I can't keep up with all the updates, but at some point in time the versions were stored in packages.config.

Or is that too complex because this requires the nuget client to submit all currently installed packages + versions to the server?

[emgarten]

@GeertvanHorrik current versions are stored in packages.config, but that doesn't include the dependency relationships between the packages.

packages.config would contain something like A 1.0.0, B 1.0.0. But it doesn't contain A -depends on-> B

[GeertvanHorrik]

Ok, makes sense, thanks for the explanation. Then I'll uninstall + install instead.

[kellyelton]

Why aren't the nuspec files just unpacked as well to skip this step?