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.

[alexrp]

Just for the record, this is now affecting Avalonia users: AvaloniaUI/Avalonia#9549

[alexrp]

Adding to all of the above that I've just had to make the decision to avoid Rx.NET in one of my projects and implement a subset of observable types myself solely because of this issue. The behavior of pulling in WPF/WinForms for -windows TFMs simply makes Rx.NET an unacceptable dependency for a library project. It's a fairly tragic state of affairs.

[glennawatson]

@HowardvanRooijen recently took over ownership of this project, so hopefully he can put this on the board to be looked at. Agreed the issue hasn't been great in regards to implied WPF support and has caused issues for ReactiveUI as well.

[HowardvanRooijen]

Adding to all of the above that I've just had to make the decision to avoid Rx.NET in one of my projects and implement a subset of observable types myself solely because of this issue. The behavior of pulling in WPF/WinForms for -windows TFMs simply makes Rx.NET an unacceptable dependency for a library project. It's a fairly tragic state of affairs.

Keep an eye on #1868

[idg10]

As the recently published roadmap at https://github.com/dotnet/reactive/blob/main/Rx.NET/Documentation/Rx-Roadmap-2023.md#rx-v70 says, fixing this is a primary goal for Rx 7.0. (We're not quite ready to move on that because we have some test failures we've not yet resolved as part of migrating everything over to current SDK and VS versions for Rx 6.0, and those problems need to be fixed before we can move forward on v7.0)

We haven't yet finalized a plan for how we will fix the problems described in this issue, but our current thinking is that we need to separate all of the UI-framework-specific code out of the main System.Reactive component. Our current view is that if you want, say, Windows Forms support, then you will need to ask for that by referencing some Windows-Forms-Specific component. This will be a breaking change because projects that are today happily using the Windows Forms integration via a single reference to System.Reactive will now need to add a reference to an additional component.

It's possible that System.Reactive will then only be available as a netstandard2.0 package, although if find clear reasons that net6.0 and, if necessary, also net7.0 versions are absolutely necessary, we'll produce targets for those as well.

The history behind the decision to unify everything under a single component is complex, and we need to make sure that we don't recreate any of the old problems that the unification was intended to fix. We believe that the ways in which the various .NET runtimes still in support have evolved since that decision was taken means that we won't be reverting to these old problems, but we do need to make absolutely certain of that.

[idg10]

People running into this issue could try adding this to their project files as a workaround:

  <PropertyGroup>
    <DisableTransitiveFrameworkReferences>true</DisableTransitiveFrameworkReferences>
  </PropertyGroup>

We think this is a viable workaround. It essentially undoes Rx's attempt to add the unwanted desktop framework reference. In our experiments this is sufficient to prevent the packaging bloat problems. However, if people are finding that this doesn't work, we really want to know because this workaround is provisionally part of our long term plan for fixing this.

Our view is that if a viable workaround is available, we don't need to do anything radical in the short term. We can gradually deprecate the use of the UI-framework-specific types that are baked into System.Reactive today. The long-term goal is that System.Reactive should contain nothing UI-framework-specific, but that it will take many years to get to that end state because to remove these types today would cause breaking changes for many current users of Rx. Deprecation needs to occur slowly.

However in the absence of a viable workaround, radical change may be unavoidable. In that case, we might need to do the thing we really want to avoid: changing the main Rx package, leaving System.Reactive as a mere type forwarding shim preserved for backwards compatibility reasons. We really don't want to do that, but if people don't have a workaround for this issue, we may have no choice.

So that's why it would be very helpful for us to know if this workaround doesn't work.

[wmanning]

See here for discussion on DisableTransitiveFrameworkReferences: #2038 (reply in thread)