Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert change that instructs you to target netX.0-windows10.0.19041 #1893

Closed
idg10 opened this issue Mar 13, 2023 · 0 comments · Fixed by #1901
Closed

Revert change that instructs you to target netX.0-windows10.0.19041 #1893

idg10 opened this issue Mar 13, 2023 · 0 comments · Fixed by #1901
Milestone

Comments

@idg10
Copy link
Collaborator

idg10 commented Mar 13, 2023

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.

@idg10 idg10 added this to the Rx 6.0 milestone Mar 13, 2023
idg10 added a commit that referenced this issue Mar 17, 2023
This seems to cause more problems than it solves - see #1893

Once we separate the UI frameworks back out into their own packages, the
issue that PR was intended to solve will go away in any case.
@idg10 idg10 mentioned this issue Mar 17, 2023
@idg10 idg10 linked a pull request Mar 17, 2023 that will close this issue
idg10 added a commit that referenced this issue Mar 27, 2023
The original PR seems to cause more problems than it solves - see #1893

Once we separate the UI frameworks back out into their own packages, the
issue that PR was intended to solve will go away in any case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant