[PR] Support for default generic *-windows moniker in ReactiveUI.WPF
the-black-wolf opened this issue · 1 comments
Continuation of #3557, template is there, we can copy it over if you like.
Since you said you guys don't want to waste time, I "wasted" some of mine. I analyzed the problem, and the issue with upstream dependency in System.Reactive for -windows is EXACTLY the same you had with windows10.0.17763.0, and the same solution applies.
The overrides you made for 17763 work perfectly in a generic -windows target and can be safely used.
I made a PR with the change, also combined 17763 triggers into one, will post it in a minute when I get the issue number.
Explanation:
The issue in upstream dependency seems arbitrary and artificial. It is caused by the improperly defined HAS_WPF condition which is only set for 19041 target (how quaint), effectively removing DispatcherScheduler from the net6.0 without exposing the same functionality to net6.0-windows target.
Didn't waste too much time right now analyzing why in the upstream repo because I already found a fix, but I guess it was just a way for them to "fix" some other issue not directly related to DispatcherScheduler, or it was a leftover from a missing dependency from net5.0, and figuring that out requires more analysis, because ultimately I see no specific Windows release dependency or P/I call, so do not immediately see what prevented net6.0-windows target. Regardless, its a completely different can of worms, starting with the fact they should have made a System.Reactive.WPF package targeting -windows if they wanted to mess with WPF, that code should not have been part of the core System.Reactive to begin with.
For this particular scenario, the widest usability of ReactiveUI.WPF, and more precisely for -windows targets: binding to net6.0 and adding missing class SOLVES the problem, same as for 17763.
I tested it on a net7.0-windows targeted wpf app in various scenarios and everything seems to work just fine, but the key point, the DispatcherScheduler standin, I stepped through it and it works perfectly.
Kindly review my changes and include this PR into the main ReactiveUI.WPF for the next release. If you need me to update IntegrationTests.WPF (since right now it only really tests the .net framework build), let me know, I will be willing to help with that too.
When I have more time, I will try to investigate the System.Reactive issue and work with RxTeam, see if we can get a usable net6.0-windows target out of it, if so, the project could be simplified further and not depend on spaghetti OS specific targets and detached copies of classes. If Microsoft wants to obsolete window 7 in dotnet, they can easily do that themselves by changing the mapping of -windows from -windows7.0 into -windows10.0 in the next release, as it should be done in the new brave post 5.0 world, since they are the ones who allowed this nightmare combinatorial explosion of targets in the first place. Despite their OWN conclusion it is bad (see "Why are the OS specific flavors not versioned by the OS?" in https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md). This shouldn't be the concern of library designers who should strive to have their packages as widely targetable as possible.
PS: Kindly, In the future, please do not be so quick to silence and shutdown conversations. I can appreciate some of you are busy, but I am trying to help you overcome an unnecessary technical limitation, and being shutdown without being given a chance to explain my position or contribute was kind of rude. Especially since you stated that external PRs are welcome. Now we have two issues for something that could have been done in the first one.
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.