Why does ReactiveUI have a dependency on an old version of System.Reactive?

Question

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

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

The ReactiveUI package appears to depend on an old set of reactive packages (RX-Core2.2.5 etc.). I can tell this because the HintPaths in the WPF applicatio project file are pointing to locations such as packages\Rx-Core.2.2.5\lib\net45\System.Reactive.Core.dll

When I build and run the application I get a FileLoadException since at least one of the projects is attempting to use the wrong dll version. 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's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I might be able to fix this up by downgrading all System.Reactive packages across the solution to 2.2.5 but this appears to be a very old version (2014).

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

Achorn

Answer 1

This is explained in this issue on github. Long story short - new version of Reactive Extensions appeared late in the development cycle of RxUI 7.0, so the team decided to skip it for this release. It helps people maintaining existing apps - they can upgrade RxUI version without bumping Rx version at the same time. Taking dependency on latest Rx is planned for RxUI 8.0 release.

As @shiftkey states it:

Due to the minor API churn that System.Reactive 3.0 introduced (it was more about the infrastructure and getting things into the foundation), and the fact that RxUI 7.0 was already so close, it was decided that it was easier to leave that out for the next major release.

And yes, with all the infrastructure work now in place we are aiming to keep the RxUI 8 release cycle focused.

One side note. The fact that Rx 2.x hasn't been updated in such a long time (2014) is not as bad as it may look - this is a really solid piece of tech, and you can use it without worries. The upgrade to 3.0 did not change much API-wise (and did not introduce breaking changes) so if you stick to 2.x for now, the upgrade later in your project cycle should not be painful.

Nonetheless, if you really want to use Rx 3.0 with RxUI today, I suggest you to join the project slack channel and participate in the project, by testing bleeding edge releases and contributing yourself :)

Lorettalorette