Does nuget have a solution for including packages that depend on different versions of one package?

Topics: General
Feb 4, 2014 at 9:01 PM
I posted this on StackOverflow but decided I might get more traction here.

I know this was an issue that was pointed out when nuget started but I have no idea what the current state of affairs is.

I am already using the DocumentFormat.Ooxml package and would like to also use ClosedXml which depends on an older version of the same library so I get:
PM> Install-Package closedxml
Attempting to resolve dependency 'DocumentFormat.OpenXml (= 1.0)'.
Installing 'DocumentFormat.OpenXml 1.0'.
Successfully installed 'DocumentFormat.OpenXml 1.0'.
Installing 'ClosedXML 0.69.2'.
Successfully installed 'ClosedXML 0.69.2'.
Install failed. Rolling back...
Install-Package : Already referencing a newer version of 'DocumentFormat.OpenXml'.
Does nuget actually have a solution for this situation? Even if I could do assembly redirection (which I've always had mixed results with in unit tests) I don't see a -Force parameter on Install-Package.
Feb 9, 2014 at 10:22 PM
There are no plans at current for allowing multiple versions of a package to be installed into a single project at once. This would generally lead to conflicts as there would need to be 2 assemblies with the same name referenced (and in the bin folder).

The issue here is that ClosedXML has a version-specific dependency on DocumentFormat.OpenXml. You can contact the owner of ClosedXML to see if they can publish a new version that allows for different versions of DocumentFormat.OpenXml to be used.

If that isn't successful, then you can try to break yourself out of this conflict by doing the following:
  1. Install-Package DocumentFormat.OpenXml [to get to your starting point]
  2. Install-Package ClosedXML -ignoreDependencies [to install it, ignoring its dependencies]
This will result in a binding redirect getting added to your app/web.config file, like this:
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="DocumentFormat.OpenXml" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="2.5.5631.0" />
Then you'll need to test your consumption of ClosedXML to see if the newer version of DocumentFormat.OpenXml can really be used with it. If it works, you'll certainly want to let the owners of ClosedXML know that (using the Contact Owners link on for the package), so that they might move forward with updating the package with a new version that allows the newer DocumentFormat.OpenXml.

Hope this helps,
Feb 10, 2014 at 8:04 PM
Thanks for the response Jeff,

What is the nuget team's general attitude toward the issue? I understand that implementing support for multiple versions of the same assembly would be really hard but is there a general agreement that this is something that will eventually need to be tackled or is the very necessity of this still up for debate?
Feb 11, 2014 at 2:10 AM
The very necessity (and more so the practicality) is still up for debate. It mostly comes up when dealing with content file / client-side packages like jQuery.