RxApp.MainThreadScheduler running on WinUI 3

[oliverw]

Inspecting RxApp.MainThreadScheduler in the debugger revealed its a ReactiveUI.WaitForDispatcherScheduler, but shouldn't it be a SingleWindowDispatcherScheduler?

Just want to make sure I didn't miss any initialization stuff I'm supposed to call.

[glennawatson]

Yeah should be. Sometimes I seen this type of thing when you're not using new enough net6.0 windows version.

We've had to adopt a fairly late version due to downstream windows nuget dependencies.

[oliverw]

Can't be the .NET Version as the machine is fully up to date.

So I am missing something else perhaps?

  <ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.2.230118.102" />
    <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.755" />
    <PackageReference Include="ReactiveMarbles.ObservableEvents.SourceGenerator" Version="1.2.3">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="ReactiveUI.WinUI" Version="18.4.20" />
    <PackageReference Include="WinUIEx" Version="2.1.0" />
    <Manifest Include="$(ApplicationManifest)" />
  </ItemGroup>

[anaisbetts]

It should be a WaitForDispatcherScheduler that encapsulates the correct scheduler. This scheduler was written to encapsulate UWP brain-damage where the dispatcher explodes until later in app startup, which probably applies to WinUI 3 too

[glennawatson]

Not UWP with WinUI so don't think that's the issue.

[anaisbetts]

Well then.......never mind! 😅

[oliverw]

Not UWP with WinUI so don't think that's the issue.

Is there any manual RxUI setup the (WinUI) App is supposed to call that I might be missing?

[anaisbetts]

This is all implementation details that should be handled by initialization @oliverw, you shouldn't have to worry about this! I think the thing to know is, if you see WaitForDispatcherScheduler, dig into its fields and see what the real underlying scheduler is

[oliverw]

This is all implementation details that should be handled by initialization @oliverw, you shouldn't have to worry about this! I think the thing to know is, if you see WaitForDispatcherScheduler, dig into its fields and see what the real underlying scheduler is

Oh, I thought your previous comment meant that you agree with Glenn that WaitForDispatcherScheduler is the wrong one. 😄