Revert change that instructs you to target netX.0-windows10.0.19041 #1893
Description
As discussed at #1889 (comment), PR #1442 looks like it might cause more problems than it solves.
The following two tables, extracted from that original comment, cover the most important facts. With today's Rx 5.0 package, here's what happens with a variety of host application TFMs and developer intentions:
| App TFM | Want WPF/WinForms? | Rx TFM | Effect |
|---|---|---|---|
net5.0 |
No | net5.0 |
App gets the non-WPF/WinForms Rx |
net5.0-windows |
No | net5.0 |
App gets the non-WPF/WinForms Rx |
net5.0-windows |
Yes | net5.0 |
Developer baffled by missing support for WPF/WinForms |
net5.0-windows10.0.19041 (or later) |
No | net5.0-windows10.0.19041 |
App gets the WPF and WinForms functionality whether or not it's wanted (which causes horrendous app bloat for some .NET app packaging models); Developer can't choose simply to use the non-WPF/WinForms version |
net5.0-windows10.0.19041 (or later) |
Yes | net5.0-windows10.0.19041 |
App gets the WPF and WinForms functionality |
@dotMorten's change was designed to address the 3rd entry in that list, where the developer wants either WPF or Windows Forms features, but hasn't realised that they need to make their app target an OS-version-specific in order to get those features.
Here's the situation after @dotMorten's change:
| App TFM | Want WPF/WinForms? | Rx TFM | Effect |
|---|---|---|---|
net5.0 |
No | net5.0 |
App gets the non-WPF/WinForms Rx |
net5.0-windows |
No | net5.0 |
Build error telling developer to make their app target net5.0-windows10.0.19041 or later; Developer can't choose simply to use the non-WPF/WinForms version |
net5.0-windows |
Yes | net5.0 |
Build error helpfully telling developer what to do |
net5.0-windows10.0.19041 (or later) |
No | net5.0-windows10.0.19041 |
App gets the WPF and WinForms functionality whether or not it's wanted (which causes horrendous app bloat for some .NET app packaging models); Developer can't choose simply to use the non-WPF/WinForms version |
net5.0-windows10.0.19041 (or later) |
Yes | net5.0-windows10.0.19041 |
App gets the WPF and WinForms functionality |
Neither of these is good, but our concern is that since Rx 5.0 has been out for 2 years without @dotMorten's change ever being included, this would risk breaking a lot of code.
As described in our 2023 roadmap our plans are roughly as follows:
- v6.0: support .NET 6 and .NET 7 and enabling building on current version of Visual Studio and recent .NET SDKs, while making as few changes as possible
- v7.0: address the numerous problems around UI framework support in Rx properly by splitting UI framework code back out into separate packages
That change in v7.0 is, we believe, a better solution to the problem #1442 attempts to address. Developers need to be able to decide whether they want WPF or Windows Forms features independently of their choice of target runtime. (So they should be free to target, say, net6.0-windows10.0.19041 without being forced to have Rx's WPF and Windows Forms features.)
Since a) in v6 we don't want to aggravate the existing situation in which people end up with unwanted WPF and Windows Forms dependencies and b) we believe we can provide a better solution in v7, we want to undo the change in #1442. This will make Rx 6.0 behaviour will be consistent with what's in the currently shipping Rx 5.0.