reactive: ILRepack causes issues with the PlatformEnlightenmentProvider

When Rx.NET v3 is used in a library as an internal dependency and which uses ilrepack to internalize that dependency before building a Nuget package, and that package is used in another project (which by itself might use a flavor of Rx.NET), the resolution of the platform-specific enlightment provider fails with:

System.InvalidCastException: Unable to cast object of type ‘System.Reactive.PlatformServices.CurrentPlatformEnlightenmentProvider’ to type ‘System.Reactive.PlatformServices.IPlatformEnlightenmentProvider’

With v2, the exact same thing happens, but you could work around that by explicitly setting the enlightment provider like this:

PlatformEnlightenmentProvider.Current = new CurrentPlatformEnlightenmentProvider();
EnlightenmentProvider.EnsureLoaded();

Unfortunately the Current property no longer has a setter. Now what?

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 15 (7 by maintainers)

Most upvoted comments

@ButchersBoy please file a separate issue on that so we can track/fix it

clairernovotny on Aug 24, 2016

Here you go #265 / #266

gluck on Aug 19, 2016

@gluck It would seem to be worthwhile to address the issues that lead you to tune the PlatformEnlightenmentProvider directly as the goal for 4.0 is to remove enlightenments all-together…the only reason it was even present was to facilitate a weird PCL split without using either cross-compiling or “bait and switch.”

One of the goals for v4 is to combine the majority of the code into a single library #199. With that, there’d no longer be a need for that mechanism either.

Can you please file issues for each of the gaps you’ve outlined?

clairernovotny on Aug 19, 2016

We also heavily use this scenario (repacking Rx), benefits is that we have (for instance) modules using Rx 1.11.1111 (yeah I know) running side-by-side (same AppDomain) with others using Rx 2.2.5, and potentially (or not, given this issue 😄 ) with others running Rx3. It allows for module-by-module non-mandatory upgrades/migrations, and not platform/big-bang style.

Regarding bait and switch, it can be troublesome but feasible: you need make your package also a bait-and-switch-like (create one assembly per platform by repacking your target assembly with the right dependencies for this platform, and repack the PCL one with the PCL bait assembly).

gluck on Aug 19, 2016