This project has moved and is read-only. For the latest updates, please go here.


Slimmed down Mono-compatible version


Mono doesn't have a few of the assemblies you reference in your main Rxx project. Specifically it doesn't have Presentation and PresentationCore (I think I have the names right). Taking Rxx.dll and using it on Mono then produces some errors.

I added a "Slim" configuration and then just searched for all the .cs files which mentioned "Windows" outside of a comment and just surrounded the file with a "#if !Slim/#endif". This was basically all of the WPF ViewModel, Control & Command stuff. Once I built this version I was able to use it on Mono 3 just fine (the compiler even stripped the assembly references to Presentation from the output assembly for me since it saw they weren't being used).

This is just a request for you to create a similar Rxx target as part of your project. Instead of calling it "Rxx - Mono" you could even call it a "Rxx - Server Profile" or something since it is just dropping out the UI-related stuff.

An alternative that might keep the maintenance a bit easier is to move this Windows-specific UI-related stuff out of "rxx" and into a separate assembly. If someone wants it, they'd just add it alongside the rxx assembly.

Just as "RxJs" doesn't include the bindings for the different JS libraries. It is just the core Observable operators. And there are separate files to add the bindings for jQuery, Node, etc.

Closed Jan 30, 2015 at 2:53 PM by davedev
The .NET 4.0.3 portable library targets mono as well. Also, all UI-related APIs have been removed. I made add modern versions back again in a new Rxx-UI project in the future.


davedev wrote Feb 4, 2013 at 11:36 AM

Thanks for reporting this issue.

What you describe is similar to the Rxx-Portable 4.5 project, which targets .NET 4.5 and Windows Store. Mostly it's the same as the main Rxx project but without any UI features. Does that work on Mono?

davedev wrote Feb 4, 2013 at 11:42 AM

Actually, portable Rxx is also missing some other components, such as socket extensions. So it's not exactly the same.

I'll consider adding an Rxx-Mono project and eliminate just the UI features. (I'd prefer a separate project rather than a symbol so that the output can be built by the build system as is without having to do multiple passes on the primary project.)

bman654 wrote Feb 4, 2013 at 2:35 PM

Yes my change was a quick hack to get what I needed and not suitable for pushing to you.

I must admit everytime I see the Portable versions I walk away confused. It looks like to be portable you have to give up Rx.PlatformServices. I'm building a server application spread across Windows (.NET) and Linux (MONO). Using all the v4.5 server-side features like TPL, threads, sockets, etc. Rx.PlatformServices isn't really something I want to give up.

FWIW I am using this same slimmed down RXX version on our Windows server also -- no need for it to have references to UI assemblies. So it is not really specific to Mono. Calling it a "Mono" version may be doing it (and Mono) a disservice. I just didn't have time to investigate if there was some mono-version of the Presentation assemblies.

If it will help, I can give you a list of the .cs files I "cut" to make this version.

davedev wrote Feb 4, 2013 at 4:01 PM

looks like to be portable you have to give up Rx.PlatformServices.
No. System.Reactive.PlatformServices assemblies provide platform-specific services, but Rx's core only depends on a service abstraction layer. When developing a portable library (such as Rxx-Portable) you can't reference any platform-specific features or System.Reactive.PlatformServices assemblies, but when you reference a portable library in a platform-specific project, such as WPF, Windows Store, Windows Phone or Silverlight, then you should also reference the System.Reactive.PlatformServices assembly for that particular platform. Rx's core will dynamically pick up the platform-specific features at runtime if the assembly is present. I believe its features generally include platform-specific optimizations for Rx's internal concurrency abstraction layer (CAL), improving the quality of schedulers and timers.

However, as mentioned, it is true that Rxx-Portable must give up public features that aren't supported by all of its target platforms in the portable library; e.g., .NET Sockets aren't supported by Windows Store apps. However, Windows Store has its own socket library, so perhaps a future version of portable libraries will support them in a portable way.
[snip] Calling it a "Mono" version may be doing it (and Mono) a disservice.
I just didn't have time to investigate if there was some mono-version of the Presentation assemblies.
Well, that's exactly why I'd call it Rxx-Mono. Even if Mono doesn't have its own implementation of WPF now, it may have one in the future. The Rxx-Mono project is exactly where that support would go. It's also where I'd put bug fixes and additional features that are specific to the Mono implementation.

Ultimately, Mono is just another platform like Windows Phone, Silverlight and Windows Store (portable), each of which have their own dedicated projects in Rxx.

RE: Server
I understand that referencing a single Rxx assembly on both the server and client seems wasteful, considering that each only uses a subset of the functionality offered. But the surface area of UI-related features in Rxx is pretty small, and the server-related features can be used on clients as well.

The original idea was that it's easier for people to understand and consume if it's only a single assembly. As I add more features to Rxx that may be changing.

I'll consider separating Rxx into different assemblies in the future. I'll add a new work item. But I think for Rxx 2.0 it's probably going to stay as a single assembly.

wrote Feb 21, 2013 at 11:46 PM

wrote Jan 30, 2015 at 2:53 PM

wrote Jan 30, 2015 at 2:54 PM

wrote Dec 8, 2017 at 5:36 AM