NETSDK1082 if installed on WinUI project targeting 19041 or higher

[huoyaoyuan]

Bug

Despite our best efforts, bugs can slip into releases or corner cases forgotten about. We will try our best to remedy the situation
and/or provide workarounds. Note that certain (odd) behaviors are by design and as such are not considered bugs.

Which library version?

System.Reactive 5.0.0

What are the platform(s), environment(s) and related component version(s)?
WinUI 3 Preview 3 project

The winui template targets Windows 18362. When installing Rx, everything is OK.

However, if the target platform is set to net5.0-windows10.0.19041, msbuild will try to add a FrameworkReference to Microsoft.WindowsDesktop.App, add results in NETSDK1082 for missing arm64 rid.

It assumes Windows Desktop support always available on Windows, but it's not the case for ARM64.

[glennawatson]

This seems to be causing issues for WinUI 3 support for ReactiveUI. If we can get some progress on this issue that would be good.

[clairernovotny]

ARM should be supported on net6.0. I don't think much is likely to change before then.

[huoyaoyuan]

Even if ARM is supported, referencing WinForms is still a wrong action.

[clairernovotny]

The -windows TFM brings in all of the Windows API. That's by design. You don't have to use them if you don't want. If you're targeting Windows, then you get the entire surface area.

[marcpiechura]

Any updates on this issues or plans to resolve it?
We've encountered the same problem as in #1607 and deactivating Resharper isn't really and option either. Downgrading the target platform to 18362 fixes the issue for now, but isn't a long term solution.
Using WinUI 3 with System.Reactive and Resharper doesn't seem like a rare use case, so couldn't the framework depended bits (WPF/WinForms/WinUI3) be moved into separate packages, so that one only needs to reference what he actually needs?

Thanks in advance and a happy new year

[clairernovotny]

Does this happen without Resharper installed/enabled?

[marcpiechura]

Nope and I raised an issue their too, but even without the Resharper issue, we've to carry around ~20MB of dlls we don't need and that would also be true for other types of projects, e.g. a console application, only because they choose to target windows only.

Actually it's worse than 20MB, just tried it out and if I publish a self contained project for windows without System.Reactive it's ~80MB, with System.Reactive it's ~175MB.

[huoyaoyuan]

@clairernovotny Things are worse in WinUI, since WPF and WinForms are unnecessarily carried for 3 platforms, increasing ~60MB for each platform after installation, and ~20MB in the installer package.

[huoyaoyuan]

The -windows TFM brings in all of the Windows API. That's by design. You don't have to use them if you don't want. If you're targeting Windows, then you get the entire surface area.

Strictly speaking, no. WinForms and WPF are opt-in by UseWinForms and UseWPF properties. Unlike .NET Framework, referencing unnecessary component does have cost since there's self-contained publishing.
Trimming is not an option here since it's not compatible with WinUI yet.

[ScarletKuro]

Things are worse in WinUI, since WPF and WinForms are unnecessarily carried for 3 platforms, increasing ~60MB for each platform after installation, and ~20MB in the installer package.

Similar issue #1745

The -windows TFM brings in all of the Windows API.

IMO, that's bad idea in general. Not only because of the app size, but the TFM brings a lot of confusion as well. It's enough to look on the amount of issue tickets it produced in this repository.
For example, people who use only WPF and want to use ObserveOnDispatcher do not understand why they need to target windows10.0.19041. Some people also start to think that if they set windows10.0.19041 for WPF project that it means it will work only on windows10+, which is false.

Probably, would vote for separate package for each platform
System.Reactive.WPF -> DispatcherScheduler + extension methods.
System.Reactive.WinForm -> ControlScheduler + extension methods.
System.Reactive.UWP -> CoreDispatcherScheduler + extension methods.
System.Reactive.MAUI-> ...
etc

Even if it would mean a less discoverable approach.