Two Nuget Packages references conflicting reactive libraries

Question

My problem is very similar to that mentioned in this post:

System.ObservableExtensions.Subscribe: ambiguous reference

I would like to use the "GraphQL for .NET" nuget package and the "Plugin.BluetoothLE" package.

"GraphQL for .NET" references System.Reactive.Core and "Plugin.BluetoothLE" references System.Reactive

As stated in the other post:

Upon further investigation I found that ObservableExtensions exists both System.Reactive.Core and System.Reactive.

How do I resolve this? "Plugin.BluetoothLE" has System.Reactive 4.0.0 and "GraphQL for .NET" has System.Reactive.Core 3.1.1.

Is there a way for me to upgrade System.Reactive.Core inside GraphQL?

Answer 1

I havent tried this below but you can see on their github it was described as breaking change and there is workaround. see the highlighted sentence below.

v4.0 changes

Due to the overwhelming pain that fixing #205 - Implement assembly version strategy caused, we have refactored the libraries into a single library System.Reactive. To prevent breaking existing code that references the v3 libraries, we have facades with TypeForwarders to the new assembly. If you have a reference to a binary built against v3.0, then use the new System.Reactive.Compatibility package.

Supported Platforms Rx 4.1 supports the following platforms

.NET Framework 4.6+ .NET Standard 2.0+ (including .NET Core, Xamarin and others) UWP Notably, Windows 8, Windows Phone 8 and legacy PCL libraries are no longer supported.

v3.0 breaking changes

The NuGet packages have changed their package naming in the move from v2.xx to v3.0.0

Rx-Main is now System.Reactive Rx-Core is now System.Reactive.Core Rx-Interfaces is now System.Reactive.Interfaces Rx-Linq is now System.Reactive.Linq Rx-PlatformServices is now System.Reactive.PlatformServices Rx-Testing is now Microsoft.Reactive.Testing This brings the NuGet package naming in line with NuGet guidelines and also the dominant namespace in each package. The strong name key has also changed, which is considered a breaking change. However, there are no expected API changes, therefore, once you make the NuGet change, no code changes should be necessary.

Answer 2

One of two ways

1. Try setting Nuget to get the minimum version to the lowest one listed by your packages.
2. Split out the operations into separate libraries and manage the differing package version specific to library.