Behavior change in how NuGet updates dependency packages

Topics: Ecosystem, General
Mar 15, 2013 at 12:47 AM
I'm writing to announce an upcoming change of behavior in how NuGet 2.3 will update dependency packages during package installation.

The scenario:

The source repository contains package B with version 1.0.0 and 1.0.2. It also contains package A which has a dependency on B (>= 1.0.0).

Assume that the current project already has package B version 1.0.0 installed. Now you want to install package A.

In NuGet 2.2 and before:

When installing package A, NuGet will auto-update B to 1.0.2, even though the existing version 1.0.0 already satisfies the dependency version constraint, which is >= 1.0.0.

From NuGet 2.3

From 2.3, NuGet will no longer update B, because it detects that the existing version 1.0.0 satisfies the dependency version constraint.

Here's the bug which prompted this design change We believe this will result in less undesired situations in which upgraded packages cause incompatibilities with other packages in the same project.

Please feel free to leave your comments or feedbacks if we have overlooked any scenario.
Mar 15, 2013 at 8:36 AM
So, there will still be an auto-update, except if the dependency constraint is already satisfied. Correct?
Mar 15, 2013 at 11:39 AM
Yes! I'm very happy with this change, because I want to be able to make dependency changes in minimal increment, because it makes it much easier to debug when something breaks. And indeed it avoids rushing into incompatibilities when other packages may not support the newer versions.
So being able to install A without necessarily updating all it's dependencies is a big win!

There is a couple of closely related scenario which I would like to bring up:

Scenario 1 : Update has a new dependency:

The source repository contains package B with version 1.0.0 and 1.0.2. It also contains package A with version 1.0.0 and 2.0.0. A 1.0.0 has no dependencies, but A 2.0.0 has a dependency on B (>= 1.0.0).

Assume that the current project already has package A version 1.0.0 and package B version 1.0.0 installed. Now you want to update package A to 2.0.0.

Scenario 2 : Update has the same dependency:

Same as above, except both A 1.0.0 and A 2.0.0. have a dependency on B (>= 1.0.0).

I believe that in both cases nuget should just update A and not update B, because the existing version of B satisfies the dependency version constraint. Is this also considered in the proposed behavior ?

(Of course this only applies when requesting the update of a specific package, and not when updating all packages).

PS: this behavior changes addresses at least partially the feature request, which was briefly discussed here
Mar 15, 2013 at 1:04 PM
@cordifed: correct
Mar 15, 2013 at 1:08 PM
Edited Mar 15, 2013 at 1:08 PM
@brogerri: Yes, with the new behavior, NuGet won't update B, in both scenarios.

Sorry I missed the other thread. I'll reply to it.
Mar 16, 2013 at 12:56 AM
Hi brogerri,

I think this change will cover your request in 3011 completely. What else do you think it still missing from your feature request?
Mar 18, 2013 at 10:25 AM
Nothing, I think. I had doubts because I didn't know what would be the behavior when updating a package, but you have cleared that up now.
Mar 20, 2013 at 11:38 PM
Note that partly because of this behavioral change, we've decided to rename the NuGet 2.3 release to NuGet 2.5.
May 11, 2013 at 10:12 PM
My only suggestion is to add an example to that makes it more obvious to readers how to 'get latest, within range, of all dependencies' for their own package(s).
Feb 10, 2014 at 6:09 AM
Wow, this change in behavior is unexpected and looks like is breaking my releases. I'm expecting my dlls to work with the latest version of the dependencies, not the oldest ones. I'm surprised this behavior makes sense as default in a continuously deploying environment as everyone's now getting older/buggier version of the code even when there's a more up to date release available.

What's the best way to revert back to the old behavior?

Can I just bump the MINOR version number instead? e.g:


to update to:


Will this bring in other v1.1.0 dependencies or continue to bring in the old v1.0.1 if they exist?
If not what should I do, update the version constraints for each package everytime I deploy?