NuGet 1.6 is automatically updating dependent packages, even when the dependency has already been satisfied.

Dec 22, 2011 at 7:58 PM

Here's an example:  

NHibernate v2.1.2.4000 has a dependency on log4net >= v1.2.10


  1. In your project run:  Install-Package log4net -Version 1.2.10
  2. Then run:  Install-Package NHibernate -Version

While installing NHibernate v2.1.2.4000, it automatically updates log4net to v1.2.11, even though the dependency was already satisfied.

This is a problem because you may have other projects in the same solution that are still using 1.2.10, and now you've references to two different packages in the same solution.

Dec 22, 2011 at 8:06 PM

Actually, this is happening in NuGet 1.5, as well.  Only noticed now because log4net released an update at about the same time as the new version of the extension.

Still a problem for me, though.

Dec 22, 2011 at 9:16 PM
It's a problem for everyone because you can't use binding redirects when a DLL is signed with a different key on every release.

On Thu, Dec 22, 2011 at 2:06 PM, afdavis <> wrote:

From: afdavis

Actually, this is happening in NuGet 1.5, as well. Only noticed now because log4net released an update at about the same time as the new version of the extension.

Still a problem for me, though.

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Dec 22, 2011 at 9:18 PM
In my opinion it should use the existing one, but there is something in the algorithm that makes a determination below the minor version.
Dec 22, 2011 at 9:21 PM
Edited Dec 22, 2011 at 9:26 PM

Absolutely.  I realize now that, in this case, it's ultimately a problem with log4net because they signed their assembly with a different key.  However, NuGet automatically gets that bad release, and there's nothing you can do to stop it.

Dec 22, 2011 at 9:34 PM
Edited Dec 22, 2011 at 9:35 PM

Yes, this is by design. When you install a package, we try to pick the dependency package that has the lowest major+minor numbers, but with the highest build+revision numbers (as long as it satisfies the dependency version specs). That's why log4net 1.2.11 was picked in your case.

The good news is that there is a way to prevent it if you don't like that behavior. Look at the section "Constraining Upgrades to Allowed Versions" in this doc:

You will want do that before installing NHibernate.

Dec 22, 2011 at 9:47 PM

But in this specific case the dependency is already satisfied. We don't need to update the package at all. I think Buildstarted reported a similar bug that I'm can't seem to find for some reason.

Dec 22, 2011 at 10:10 PM

Yeah, the existing bug is here.

We backglogged it because we weren't sure if it would be common. Go vote it up if you're running into it.

Dec 22, 2011 at 10:36 PM
Great to see there is something already logged on it and it is considered a bug. :D
Dec 22, 2011 at 11:04 PM

Yep. So the behavior that dotnetjunky defined is the correct behavior when the dependency is either:

1. Not yet installed.

2. Is already installed, but does not satisfy the required dependencies of the packages being installed.

In the case where it is already installed and does satisfy dependencies, we should not upgrade it. We should probably document all these minute rules somewhere. Anyone want to volunteer?

Dec 23, 2011 at 2:41 AM

Yea, I remember when this change was made (I made it :)). But it's definitely too aggressive and can cause more issues than needed.

Dec 23, 2011 at 5:13 AM

Are they really signing with a different key on every release? This seems like a crazy thing to do. Is there some reason for that?

The fact that the dependency gets updated when it doesn't strictly need to may be considered a minor bug, but changing that won't help the overall issue. e.g. if you install NHibernate before log4net, you'd still end up with log4net 1.2.11, which won't work.

So I view this primarily as a log4net versioning and signing practice issue.

Dec 23, 2011 at 5:46 AM

Good point about installing NHibernate vs. updating.  As I said, ultimately it's a log4net problem, it's just exacerbated by the overzealous updating.

Per haacked's request, I'd be happy to help out...if I knew where to document it.  I'd also be happy to help fix the defect, if someone wouldn't mind pointing me in the right direction.

Dec 23, 2011 at 1:05 PM - In all fairness it doesn't sound like they will be using a different key next release. Which will be in like, what 5 years? ;)

It should have been 2.0 if they were following a good versioning scheme. I think Chris Marisic (@dotnetchris) put it very well:!/dotnetchris/status/149493740833214464

Dec 24, 2011 at 10:27 PM

Do you think we can push those guys to re-release with a different version number? If they don't, all kind of existing NuGet packages that depend on it are going to be completely broken as in the case above. Given that log4net is pretty widely used, that seems like a very big problem to me.

Dec 28, 2011 at 5:48 PM
There was the version signed with the old key.
"Be passionate in all you do"