[Bug]: Mixing WPF and WinForms packages (`ElementHost`ing WPF controls inside WinForms) breaks MainThreadScheduler (and possibly other things)

[Metadorius]

Describe the bug 🐞

WaitForDispatcherScheduler silently breaks because apparently the dispatcher is either not created at all or not created before ElementHost appears. As a result all my .ObserveOn(RxApp.MainThreadScheduler) calls don't actually do anything.

Apparently there are also per-platform registrations that may clash, but I haven't observed the results yet.

Step to reproduce

1. Install ReactiveUI.WinForms and ReactiveUI.WPF
2. Create a WinForms app
3. Try to use .ObserveOn(RxApp.MainThreadScheduler) to switch threads

Reproduction repository

No response

Expected behavior

All should happen as normal

Screenshots 🖼️

No response

IDE

No response

Operating system

No response

Version

No response

Device

No response

ReactiveUI Version

20.1.1

Additional information ℹ️

Using net48

[ChrisPulman]

Interesting scenario I will take a look at the possibilities here, understanding that the wpf section needs to run on the wpf ui thread, but as it's a Winforms application so it will need to register the Winforms scheduler and the Winforms sections will need this thread, obviously we can't have two threads set as the MainThreadScheduler. I assume that the application uses a small amount of Wpf and is the majority Winforms.

[Metadorius]

It is indeed WinForms in the majority currently, but we're intending to phase out WinForms eventually so we started to introduce separate pages built using WPF.

Maybe as a quick fix accounting for the order of registrations would help? #3887

[Metadorius]

BTW I just tested reversed registration order for WinForms and WPF registrations, and in my case MainThreadScheduler unbroke. Apparently WinForms one doesn't outright break when used in WPF because it seems to function fine so far on the basic level.

[Yinimi]

I added some info about a workaround to #3887