NuGet stealth downgrades package when batch updating its dependencies

[maartenba]

From @carolynvs on January 7, 2016 19:57

tldr: When batch updating packages, NuGet should not downgrade other packages.

• openstack.net 1.5.0.1 did not set upper bounds on its dependencies.
• openstack.net 1.5.0.2 was released to set an upper bound to deal with the new NuGet ability to get the latest of dependencies.

After installing openstack.net 1.5.0.2, I immediately see 4 available updates (for its dependencies). This isn't ideal behavior as when I attempt to individually update any of these, it will fail with a message in the Output window. It would be better if it did not display the updates, instead of letting me try and fail but at least it doesn't do any harm. 😄

The big problem is that when I select all available updates, NuGet decides that instead of failing, it should downgrade the openstack.net package. This is bad because it was not what I requested and is unexpected behavior. I intended to update the checked packages to the latest version, not downgrade some other package. If I do not have the "Show preview window" setting enabled, or fail to carefully read it, I end up screwing up my project.

Copied from original issue: NuGet/NuGetGallery#2851

[maartenba]

Quick side note (no permanent resolution to this, but just a means of working around it): you could set the "Ignore dependencies" option

[yishaigalatzer]

We are discussing this, but at the moment we are not clear that this can actually be solved, because we actually don't model the fact that A is something that shouldn't be updated (and frankly I can see cases where it might be updated).

A simple solution is to add a downgrade warning, but I'm not sure if this is a good enough solution.

Assigning to @johnataylor to look further into the matter

[carolynvs]

Thanks for looking into it!

My preference is that if the requested batch update can only succeed by downgrading package X, then the user should be informed that package X is preventing the update and let the user handle it from there. This is what happens today when updating an individual package. The offending package is printed with its dependency range in the Output Window:

Attempting to gather dependencies information for package 'Flurl.Http.Signed.0.7.0' with respect to project 'NuGetDepsVerify', targeting '.NETFramework,Version=v4.5.2'
Attempting to resolve dependencies for package 'Flurl.Http.Signed.0.7.0' with DependencyBehavior 'Lowest'
Unable to resolve dependencies. 'Flurl.Http.Signed 0.7.0' is not compatible with 'openstack.net 1.5.0.2 constraint: Flurl.Http.Signed (≥ 0.6.2.2015062601 && < 0.7.0)'.

[emgarten]

I believe we only downgrade dependencies if the high level action was a downgrade. Here it looks like it was an upgrade that caused a child to be downgraded, right?

[carolynvs]

@emgarten Correct.

[johnataylor]

regarding the problem @carolynvs reports.

I just installed: id="openstack.net" version="1.5.0.2" and then ran Update-Package from the NuGet Console. I'm not seeing a downgrade happen, so if you could send me more details of teh exact scenario that would be great. For example the packages.config would be a good start.

This is what I saw before and after executing Update-Package.

BEFORE

id="Flurl.Http.Signed" version="0.6.2.2015062601"
id="Flurl.Signed" version="1.0.8"
id="Marvin.JsonPatch.Signed" version="0.7.0"
id="Newtonsoft.Json" version="6.0.4"
id="openstack.net" version="1.5.0.2"

AFTER

id="Flurl.Http.Signed" version="0.6.4"
id="Flurl.Signed" version="1.0.10"
id="Marvin.JsonPatch.Signed" version="0.7.0"
id="Newtonsoft.Json" version="6.0.8"
id="openstack.net" version="1.5.0.2"

[carolynvs]

@johnataylor If you look at the screenshots in the original post, you'll see that I used the GUI, not the console and it only happens when updating multiple packages (openstack.net's 4 dependencies).

Here are the steps to reproduce:

1. Make a new console app.
2. Install-Package openstack.net -Version 1.5.0.2
3. From the NuGet GUI, notice that 4 packages have updates. Check select all and then click the update button.

[yishaigalatzer]

Unfortunately we haven't gotten to this bug in 3.4 release, I'm moving out to 3.5