CODEWITHSUNDEEP
c#.net-corenuget-package
Alexander Høst
Alexander Høst

Reputation: 1028

Nuget package version resolution with different versions

I'm using a Nuget package that itself references a previous version of System.Reactive (specifically 4.3.2). I am not the maintainer and cannot change that, but would still like to use the package. However, all the projects in my solution reference a newer version of System.Reactive (5.0.0), and I am currently not at liberty to change that. This leads to a versioning conflict.

Back in the day I would use binding redirects, but we've transitioned to .NET Core and PackageRefernces recently, and it's unclear to me how I resolve such version conflicts using PackageReferences.

Two closely (I would assume) related questions then:

  1. Is it possible to resolve the above scenario, and if so, how?
  2. How would one resolve the reverse situation (newer version in external package, older version in my solution/projects)?

Upvotes: 0

Views: 1705

Answers (2)

Jon Skeet
Jon Skeet

Reputation: 1502985

Fundamentally, because you're resolving against two different major versions, there's currently no pleasant way of resolving this.

The fact that System.Reactive went from 4.x to 5.x suggests there are breaking changes, assuming it's actually following SemVer. So it's entirely possible that the package you're depending on relies on something in System.Reactive that was removed in 5.0.

Unless you want to get into loading the assemblies yourself using AssemblyLoadContext as a sort of isolation level, you're basically out of luck. .NET simply doesn't handle this situation well at the moment.

I suggest you work out the least painful way of getting everything onto the same major version. This could mean:

  • Downgrading your System.Reactive dependency
  • Persuading the maintainer of the other package to upgrade their System.Reactive dependency (which will mean them creating a new major version as well...)
  • Forking the other package so that you can upgrade its System.Reactive dependency yourself

None of these is likely to be simple, unfortunately.

Upvotes: 4

Andrew McClement
Andrew McClement

Reputation: 1408

When using .NET Core, you should find binding redirects unnecessary in this case.

I'll refer you to https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution#dependency-resolution-with-packagereference

If you are getting a nuget failure, you likely need to add a direct PackageReference to the problematic library, in order to enforce "Nearest wins" behaviour. I'm assuming the structure is something like:

Project:
  -> NugetPackage1
    -> System.Reactive (=5.0.0)
  -> NugetPackage2
    -> System.Reactive (=4.3.2)

and the suggested change would be to make it into:

Project:
  -> NugetPackage1
    -> System.Reactive (=5.0.0)
  -> NugetPackage2
    -> System.Reactive (=4.3.2)
  -> System.Reactive (5.0.0)

(Please note that this kind of failure only happens if the package requirements explicitly conflict - in this case both packages want a specific version, rather than simply a version greater than X.)

Note that if you wanted to make the direct PackageReference the lower of the two versions, that would work as well.

If the versioning conflict is a runtime exception, please post the exception.

Upvotes: 1

Related Questions