Rxx release to match Rx v2 due to old dependency

Topics: General
Oct 16, 2012 at 5:51 AM


when upgrading both Rx and Rxx I found out that Rxx has a dependency on Rx assembly System.Reactive, v1.0.10621.0, which in practice means I must include both the old and the new version of Rx when building my application. Is that intentional?

I saw that Rxx v1.3.4451.33754 was released before Rx v2, so my question is: will Rxx be upgraded (for no other reason than getting rid of old assembly references) to match Rx v2?

Oct 16, 2012 at 6:22 AM

...and that didn't work, as I can't reference two versions of the same assembly, of course. So, that means Rxx v1.3.4451 can't be used with Rx v2, which means I have to downgrade Rx and wait for the next release of Rxx.

Oct 16, 2012 at 7:38 AM


I still have several things on my TODO list for Rxx v2, which is why I haven't released it yet.

The latest source code has already been updated to reference Rx 2.0.  You can download it and build it yourself.  I've been depending on it for various apps without any issues so far, so I'd say it's stable enough.

- Dave

Oct 16, 2012 at 7:40 AM

Thanks Dave, good to know. Just wanted to make sure I didn't mess something up when upgrading/downgrading my project. I'll build it myself then.

- Henrik

Oct 16, 2012 at 7:40 AM


Note that the build instructions were written for Rxx v1, but they should still apply to Rxx v2.  Just use VS 2012 instead of VS 2010.

- Dave

Oct 30, 2012 at 12:51 AM



Seems you have the same problem in the nuget packages?

I can only use the RXX i self compiled, the nuget packages look for 1.0 , though they download RX 2.083xx?

Oct 30, 2012 at 4:35 AM
Edited Oct 30, 2012 at 4:38 AM


I can't repro the problem.  The following works for me:

  1. Create a new C# console application in VS 2012, targeting the .NET Framework 4.0.
  2. Open the Manage NuGet Packages... dialog.
  3. Search for Rxx.
  4. Click Install.

Note that under Dependencies it shows Rx-Main (≥ 1.0.11226).  After installing, I checked the project's References folder and saw that it has System.Reactive.dll from the 1.0.11226 package only.  Rx 2.x wasn't downloaded at all.  NuGet had only downloaded Rxx (1.3) and Rx-Main (1.0.11226).

NuGet isn't supposed to jump major versions like you're describing.  Did you do anything different than the steps above?

Edit: Be sure that you didn't already add a reference to Rx 2.0 yourself.  I think NuGet would see this as a newer version and would keep it instead of replacing it.

- Dave

Nov 25, 2012 at 10:12 AM

OK spot on , guess i didn't read your first reply regarding the nuget package not being updated to 2.01* ...thats why only the package i self built works..

I was doing exactly what you posted , Rx package  2, and trying to add the rxx package...guess i'll make my own package RXX for now locally.



Mar 8, 2013 at 1:31 PM
Edited Mar 8, 2013 at 1:31 PM

Any updates for the status of Rx2-matching Rxx release recently? Really looking forward for it.

P.S. Building locally is not an attractive option, because of our build system and how it works (without going much into details). I would really prefer having Nuget package for this.

Thanks in advance!

Mar 8, 2013 at 4:14 PM
Edited Mar 8, 2013 at 4:14 PM
Hi Roman,

I'm having a bit of a problem with a Code Contracts bug at the moment that is preventing me from building a release package; however, that's not really the reason why I haven't deployed a new version to NuGet in a while. At some point I decided that the cost of building, testing, documenting and deploying new release versions of Rxx to match new versions of Rx, for each of the supported platforms, wasn't worth the effort. I figured that building locally was the best solution for everyone, partially because it allows people to shrink the size of the library by eliminating the features that they don't want. But thanks for your feedback, because I realize that it's probably not the best solution for everyone, it's just me being lazy :)

Furthermore, I've been working on integrating Rxx into Rx, though admittedly it hasn't been one of my priorities recently. I'll dive back into it soon and hopefully we'll see some of the APIs rolled into Rx vNext. After that, I may continue to deploy Rxx with features that weren't absorbed into Rx.

- Dave
Mar 11, 2013 at 9:32 AM
davedev wrote:
Furthermore, I've been working on integrating Rxx into Rx, though admittedly it hasn't been one of my priorities recently. I'll dive back into it soon and hopefully we'll see some of the APIs rolled into Rx vNext. After that, I may continue to deploy Rxx with features that weren't absorbed into Rx.
Integration of Rxx into Rx sounds absolutely great! My personal favorite would be the FromPropertyChangedPattern. Another really cool thing could be implementation of certain pieces in a portable way, so that it's possible to reuse the binaries produced with those extensions between Windows Phone 8 and Windows 8. But I guess it's too forward-looking request. :)

Mar 11, 2013 at 10:17 AM
Edited Mar 11, 2013 at 10:17 AM

Yep, FromPropertyChangedPattern is on the list.

I agree that portability is the way to go. Rx now supports Windows Phone 8 in their portable library, so Rxx should too.

- Dave
Aug 2, 2013 at 12:53 PM
Cannot build from latest source due multiple Code contracts errors.
Aug 2, 2013 at 3:38 PM

Thanks for letting me know.

The latest release of the Code Contracts rewriter is more strict about the return types used in post-conditions, which is perhaps a good thing, though now it's identifying invalid return types used in post-conditions that it never identified before.

I've fixed the post-conditions and checked in the latest source code. It builds without errors for me now.

Aug 21, 2013 at 12:43 AM
It's disappointing that there isn't any official support for Rx ≥ 2.0. We lobbied hard for our team to get access to Rxx, but we were unaware of the compatibility limitation with Rx until we ran an integration test that threw an exception for the missing assembly System.Reactive. Building the source code is not a realistic option for about a half-dozen reasons.
Aug 21, 2013 at 1:44 AM

Thanks for your feedback.

- Dave
Jun 13, 2014 at 10:02 AM

is there a roadmap for rxx v2 release?

Apr 16 at 9:18 AM

Thanks Dave for maintaining Rxx (75584 revisions, wow). Thanks for documenting the build process precisely.

We've been interested in Rxx for several things for a .NET 4.0 project. The first we've been using is Stream.ReadObservable().

I saw your replies above and wholeheartedly agree about working on the most recent software, no millstone, building software from source for dependency flexibility and control (that's generally easier/more scriptable on Linux than on Windows). Yet here, too, the constraints prevent that. The current project must do without Rxx until a release is available linking with a recent Rx. :-/

It's been more than 3 years now since the last Rxx release. Is a newer build considered ?

Thanks again anyway.
Apr 16 at 11:31 PM
Edited Apr 16 at 11:31 PM
The only reason why I didn't deploy the latest version to NuGet in February as I had planned was because I was running into an automated build issue, which I still have yet to resolve. But it's certainly not a requirement -- I can build the main NuGet package manually.

Thanks for reminding me. I'll try to make time this weekend to do the deployment.

- Dave
Sep 1 at 8:17 PM
Hi there Dave

Do you have any estimates of when you'll be able to publish a more recent version of Rxx on NuGet? I really wanted to use the library for the ListSubject functionality but it seems it's still referencing Rx 1.1 instead of Rx 2.0+.

I'm trying to compile the code myself just to see if it will work, but of course I'd prefer that the NuGet package was updated.

Juliano Goncalves
Sep 2 at 11:12 AM
Hi Juliano,

I'm in the process of moving the project to GitHub:


Some other people are also still asking for a NuGet release to match the latest version of Rx. I'll see what I can do this weekend since I think I'm finally free to spend some time on OSS.