Support for core net7.0-windows moniker in ReactiveUI.WPF | please read

[the-black-wolf]

Is your feature request related to a problem? Please describe.

Unable to use default win7.0-windows moniker with ReactiveUI, this later daisy chains into inflated requirements for our clients.

Describe the solution you'd like

Unless using some very specific Windows 10 interop calls, please simplify all win7.0-window* package requirements to win7.0-windows. Do the same for net6.0 as well, since its still active.

Describe alternatives you've considered
There are no alternatives, because TFMs are hardcoded into nuget package. The only alternative is to fork ReactiveUI and make a parallel build, which I would prefer not to do, especially over this. This should be resovled at ReactiveUI level.

Describe suggestions on how to achieve the feature
change build TFMs for wpf package.

Additional context

Re the issue #3523 which is now closed.

I get that Win 7 is no longer supported, but I also wished reality is so clear cut as this. meaning there are still legacy Win7 boxes to maintain.

What exactly is preventing ReactiveUI.WPF from deploying under net7.0-windows (e.g. net7.0-windows7) or even running under it? As I see the package requires the same ReactiveUI dependency regardless of windows version, and ReactiveUI itself can run even under netstandard2, let alone net7-windows. Maybe I am wrong, but I see nothing that is required above the default win7.0-windows

Given that WPF itself binds just fine under win7, dependencies (including 3rd party UI libraries which also do not care that win7 is depracted) are all net7.0-windows, why go to all the trouble to artificially limit this? Shouldn't the guiding principle be reducing the requirements to the lowest usable?

Among other things this makes our UI libraries which use your library unable to bind on win7.0-windows which is what most WPF projects use now.

Can you please revisit this issue and simplify package dependencies?

[glennawatson]

We have downstream dependencies on reactive which has those constraints. You can attempt to get the simpler versions there first

[glennawatson]

One note. Having a larger doesn't exclude you targeting earlier versions of windows etc. you just get the bug fixes in your own programs. I'll close this one unless our downstream dependencies changes their practices.

[the-black-wolf]

@glennawatson
Which downstream dependencies are we talking about?

I do not see any net7.0-windows10* dependency in the chain before ReactiveUI.WPF package. ReactiveUI itself if platform agnostic and I see no other dependency.

[glennawatson]

System.reactive.

[the-black-wolf]

All System.Reactive.* packages bind to .netstandard2, which means they can bind just fine. There is no Windows 10 TFM requirement for any of them

Even if we talk solely about downstream dependencies, they will bind just fine on net7.0-windows. heck, we bind on Prism which is still net5.0-windows.

[glennawatson]

No it's locked down.

[glennawatson]

https://github.com/dotnet/reactive/blob/95d9ea9d2786f6ec49a051c5cff47dc42591e54f/Rx.NET/Source/src/System.Reactive/System.Reactive.csproj#L3

GitHub

reactive/Rx.NET/Source/src/System.Reactive/System.Reactive.csproj at 95d9ea9d2786f6ec49a051c5cff47dc42591e54f · dotnet/reactive

The Reactive Extensions for .NET. Contribute to dotnet/reactive development by creating an account on GitHub.

[glennawatson]

Locking the issue. We're wasting everyone time at this stage discussing a locked dependency downstream outside rxui control.