[BUG/INVESTIGATE] ReactiveCommand after >14.1.1 in WPF gets broken under certain circumstances

[ScarletKuro]

Maybe this is not really a bug, but I think it might be worth investigating, since I'm a little confused about it.

Describe the bug
After upgrading to the latest ReactiveUI(16.3.10) I noticed that ReactiveCommand CanExecute is always false - the button is disabled. Even if you don't pass IObservable<bool> canExecute in the ReactiveCommand the button still won't be active.
This problem started after >14.1.1 and higher due to these PRs(#2880, #2835). Roll backing the changes returns everything to normal.
However, this happens under certain combination.

The combo is

1. Wpf
2. ReactiveUI >14.1.1 and higher
3. Dapplo.Microsoft.Extensions.Hosting(in repro I used slightly modified own solution)
4. SimpleInjector

Steps To Reproduce
https://github.com/ScarletKuro/ReactiveCommandSideEffect

Sorry for maybe not for the most minimalistic repro, but it took me hours to find the issue and remove everything extra from not the smallest production application.

My observation

1. If we remove CustomerInputViewModel from DI the problem is gone.
2. If we remove Brush from CustomerInputViewModel properties the problem is gone.
3. If we remove SimpleInjectors.Verify(in RootBoot) method from container booting then the problem is gone.
4. If we move SimpleInjectors.Verify method to UI thread the problem is gone.

My thoughts
The SimpleInjector has diagnostic service which is really helpful. In short, it will iterate thought all registrations and check for lifestyle mismatches etc. For this it has to resolve the types first and this might happen not on UI thread which will have a side effect on ReactiveCommand.
My question is, why does this happen. Like alright, the check might not run on UI, but since the ViewModels registered as transient and when View is created(also always a new object) it will resolve the ViewModel under the correct UI thread, which is easy to check, as well as the form is running on the correct thread, otherwise the form would not show up. Also pay attention that if we remove the second ViewModel(CustomerInputViewModel or Brush properties) which doesn't even have a view it will start to work, how can these two separate ViewModel objects affect each other(CustomerInputViewModel has effect on Main2ViewModel). This is a really weird side effect for me, which might affect other users that has not "standard" application architecture.
As current solution, I moved SimpleInejectors verification in method that runs in UI thread.

[rog1039]

I have this problem all over my solution. Just started investigating it so I'm not sure what is going on at the moment. I am using Autofac, not SimpleInjector, and also am not using Dapplo.Microsoft.Extensions.Hosting either. So my only intersection with your report so far is WPF and upgrading from Reactive 14 to 16.3.10.

I am also on .net 6 in case that has any impact.

Will report back once I can figure more out.

[glennawatson]

If you are using custom di you need to call InitialiaizeReactiveUI on the splat containers to get the default threads schedulers setup on the platform on RxApp

[rog1039]

@glennawatson Thank you very much for the tip!

I followed the instructions here:
https://www.reactiveui.net/docs/handbook/dependency-inversion/custom-dependency-inversion

And things seem to be back to normal!

Thanks again!

Custom Dependency Inversion

[ScarletKuro]

Hm, I have never seen this method before, not in documentation(but apparently there is... I have overseen it because I wasn't interested in splat) or in examples.
But it does actually help, even just with a simple Splat.Locator.CurrentMutable.InitializeReactiveUI(I don't really like Splat.SimpleInjector with the AllowOverridingRegistrations workaround and I see no much sense in registering reactiveui components into SimpleInjector, i want to keep them separate). I added this in the App.xaml.
Still a little weird for me, I always thought that RxUI does the initialization once the first "reactive" component is called. And the documentation says the same you don't need to explicitly call the method, as ReactiveUI calls the method implicitly for you, and I was checking before that the RxApp.MainThreadScheduler was correct, yet it still does the "magic".

[glennawatson]

It's in the documentation for the Splat containers https://github.com/reactiveui/splat#dependency-resolver-packages

GitHub

GitHub - reactiveui/splat: Makes things cross-platform

Makes things cross-platform. Contribute to reactiveui/splat development by creating an account on GitHub.

[glennawatson]

The link above is in that documentation you linked btw, second paragraph in https://www.reactiveui.net/docs/handbook/dependency-inversion/custom-dependency-inversion#use-a-dependency-resolver-package

[glennawatson]

Alright closing this issue up, feel free if you like to contribute a PR to the github.com/reactiveui/website project to clarify the documentation on this if you like.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.