The incorrect version of a dependency is loaded


Here are the installed packages I have:

json.net 4.0.2
ravendb 1.0.499 which has a strict dependency on json.net 4.0.2

I wanted to install the latest TweetSharp (2.0.8) which is documented as:
Dependencies: json.net >= 4.0.1

When installing I get the following log:

M> Install-Package TweetSharp
Attempting to resolve dependency 'Hammock (≥ 1.2.3)'.
Attempting to resolve dependency 'Newtonsoft.Json (≥ 4.0.1)'.
Successfully installed 'Hammock 1.2.6'.
Successfully installed 'Newtonsoft.Json 4.0.3'.
Successfully installed 'TweetSharp 2.0.8'.
Install failed. Rolling back...
Install-Package : Updating 'Newtonsoft.Json 4.0.2' to 'Newtonsoft.Json 4.0.3'
failed. Unable to find a version of 'RavenDB-Embedded' that is compatible with
'Newtonsoft.Json 4.0.3'.

As you can see it tries to download and install json.net 4.0.3 which fails with RavenDB.
The already installed json.net 4.0.2 should be kept.
Closed Mar 21, 2013 at 11:43 PM by danliu
verified using the latest build. Also tried related scenarios.


dotnetjunky wrote Oct 27, 2011 at 12:18 PM

when looking for dependencies, we pick the version that has the latest build/revision numbers, which in this case is 4.0.3. Perhaps we should be smarter and search among the installed packages to see if there is any hard dependency on that package.

dfowler wrote Oct 28, 2011 at 7:13 AM

Yea, we need to be a little smarter about our update logic and maybe pick the best one (I'm sure it'll be non trivial to get right though)

Haacked wrote Nov 22, 2011 at 9:50 PM

Moving to backlog. Let's see how common this is before we fix it.

Haacked wrote Dec 22, 2011 at 9:11 PM

Related discussion here http://nuget.codeplex.com/discussions/283937 where a dependency is already satisfied and we upgrade anyways.

Valeriob wrote Sep 20, 2012 at 9:45 AM

This issue is very common on shared assembly, for example logging and ioc containers that are used by many libraries.
ES: after installing autofac-2.6.1, if i install a package that requires autofac >= 2.6.1 and on nuget autofac-2.6.3 is present, the default behavior is to uninstall 2.6.1 and upgrade to 2.6.3 even if the dependency is already satisfied, this is very frustrating on large projects.
I've heard many ppl dropped using nuget for this very reason, their package version decision get overridden even if right and i dont think is is a good behavior either.

dotnetjunky wrote Sep 20, 2012 at 4:36 PM

Bringing this bug out of back log.

JeffHandley wrote Oct 23, 2012 at 8:22 PM

What you said makes sense. If you already have autofac installed with a version that satisfies the dependency, we should leave it alone.

@dotnetjunky Can you work on this for 2.3 please?

JeffHandley wrote Oct 23, 2012 at 8:34 PM

@Valeriob Another thing you can do is constrain your installed version of the autofac package within your packages.config file.

For instance:

<package id="Autofac" version="" targetFramework="net40" allowedVersions="[2.6.1,2.6.2)" />

When I then run update-package, I get the message:

PM> update-package
Applying constraint 'Autofac (≥ 2.6.1 && < 2.6.2)' defined in packages.config.
No updates available for 'Autofac' in project 'ClassLibrary2'.

As mentioned in the discussion thread, this will address the issue when installing a package that has a dependency on something already installed, including the log4net scenario.

PM> install-package log4net -version 1.2.10
Successfully installed 'log4net 1.2.10'.
Successfully added 'log4net 1.2.10' to ClassLibrary2.

**** Update packages.config to have allowedVersions="[1.2.10]" for log4net ****

PM> install-package nhibernate
Attempting to resolve dependency 'Iesi.Collections (≥ 3.2 && < 4.0)'.
Successfully installed 'Iesi.Collections'.
Successfully installed 'NHibernate'.
Successfully added 'Iesi.Collections' to ClassLibrary2.
Successfully added 'NHibernate' to ClassLibrary2.