Why does ReactiveUI depend on the old version of System.Reactive?

Question

I have a solution for several Visual Studio.Net 4.5.2 projects. In one of the projects (WPF application), I used nuget to add the System.Reactive package version 3.0.1000.0, followed by the ReactiveUI 7.0.0.0 package.

In another project, which is the class library used by the WPF application, I just added the System.Reactive package version 3.0.1000.0.

The ReactiveUI package seems to depend on the old set of reactive packages (RX-Core2.2.5, etc.). I can say this because the HintPaths in the WPF application project file point to places like \ Rx-Core.2.2.5 \ lib \ net45 \ System.Reactive.Core.dll

When I create and run the application, I get a FileLoadException, because at least one of the projects is trying to use the wrong version of the dll. The following is typical ....

System.IO.FileLoadException occurred HResult=0x80131040 Message=Could not load file or assembly 'System.Reactive.Linq, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

I could fix this by lowering all System.Reactive packages within the solution to 2.2.5, but this seems to be a very old version (2014).

Why is ReactiveUI pulling a dependency on v2.2.5 from System.Reactive? Is there a way to change this behavior so that I can use the latest version of System.Reactive in the whole solution?

Answer 1

This is explained in this issue on github . In short, a new version of Reactive Extensions appeared at the end of the RxUI 7.0 development cycle, so the team decided to skip it for this version. This helps people maintain existing applications - they can upgrade the RxUI version without simultaneously developing the Rx version. Dependence on the latest Rx is planned for the release of RxUI 8.0.

As @shiftkey states this:

Due to a minor glitch in the API that System.Reactive 3.0 introduced (this has more to do with the infrastructure and what is happening in the foundation), and the fact that RxUI 7.0 was already so close, it was decided that it was easier to get away with this for the next large release.

And yes, now that the entire infrastructure is working, we are striving to focus the RxUI 8 release cycle.

One-sided note. The fact that Rx 2.x has not been updated for such a long time (2014) is not as bad as it might seem - this is really a solid piece of technology, and you can use it without worries. Upgrading to 3.0 did not change the API much (and did not make any changes), so if you stick to version 2.x, upgrading later in your project cycle should not be painful.

However, if you really want to use Rx 3.0 with RxUI today, I suggest you join the project’s project channel and participate in the project by testing the bleeding extreme releases and contributing :)