search

dotnet / reactive

The Reactive Extensions for .NET
http://reactivex.io
MIT License
6.68k stars 749 forks source link

Support .net 6.0 in Directory.build.targets #1725

Open ran-lc opened 2 years ago

ran-lc commented 2 years ago

Currently the build has no support for .net6.0 for specific flags that are set. We are running a .net 6.0 wpf application and the required flags are not set for certain features that we are using. We are upgrading from .net framework 4.7.2 We are using the DispatcherScheduler functionality.

Would it be possible to add .net6.0 into the Directory.build.targets?

robertcoltheart commented 2 years ago

I've started a PR to address this, but I'm stuck on what it needs to build on Azure pipelines, if anyone can assist?

robertcoltheart commented 2 years ago

@clairernovotny @danielcweber Are there any plans to perform this upgrade? Like OP above, I'm having issues with using Rx in net6.0 applications due to the above.

LuciferSam86 commented 2 years ago

It seems there are some problems with CI of the PR linked to this issue, like the wrong version of msbuild. Any news?

robertcoltheart commented 2 years ago

Yeah, not being familiar with the build setup for this repo, I wasn't sure how to proceed. Hoping one of the maintainers can step in to assist.

G31st commented 2 years ago

Any support for this ?

robertcoltheart commented 2 years ago

I updated the pool type to windows-2022 to see if it would resolve the build, however it doesn't seem to have worked.

ken-okabe commented 2 years ago

Rx.NET v6.0.1 is needed now. Thank you.

glopesdev commented 1 year ago

@danielcweber @clairernovotny @robertcoltheart I would like to help this upgrade move along either by reviewing the existing PR or even making a new one, but there are a couple of guidelines that I feel should come from the maintainers, specifically regarding which target platforms to support for Rx.NET going forward.

When thinking about this I took System.Interactive and System.IO.Ports as reference, since the former is also built and deployed from this repository and already has a net6.0 target, and the latter since it also had a similar pattern like Rx.NET of targeting a wide range of platforms in net5.0 before the upgrade to net6.0.

In both of these cases the decision was made to drop all net5.0 targets and also UAP. This seems reasonable to me since effectively .NET 6.0 is the new LTS and most legacy applications are now targeting .NET 6.0 when migrating from .NET Framework. This would essentially imply dropping netcoreapp3.1, net5.0, net5.0-windows10.0.19041 and uap10.0.16299.

The following targets would then remain: net472, netstandard2.0, net6.0 and net6.0-windows10.0.19041.

Does this sound good?

glopesdev commented 1 year ago

A related question that keeps coming up is whether the platform-specific schedulers should be bundled together with System.Reactive. Again, for parity with System.Interactive it feels like these should be split into a separate assembly (perhaps System.Reactive.Windows)?

That would leave System.Reactive fully platform-independent, possibly with just three targets: net472, netstandard2.0 and net6.0.

robertcoltheart commented 1 year ago

I've given up on my PR. I'll let someone else have a go if they want to. Radio silence from the maintainers, so I'm not even convinced it would have been merged in any case.

idg10 commented 1 year ago

@ran-lc please could you clarify what you mean by:

the build has no support for .net6.0 for specific flags that are set.

At the time you created this issue, nothing in the Rx repo had any projects with net6.0 in <TargetFrameworks>, so adding entries in the Directory.build.targets file to detect net6.0 and set flags accordingly would have had no effect—nothing in the repo would have used them because nothing targetted net6.0.

We have now done what I think you're asking for. because we do now target .net6.0. Specifically:

Does this do what you were looking for? There are 6.0.0-preview versions currently available on NuGet that make use of this if you want to try this.

We are running a .net 6.0 wpf application and the required flags are not set for certain features that we are using. We are upgrading from .net framework 4.7.2 We are using the DispatcherScheduler functionality.

This functionality is in fact available with Rx 5.0. You need to target net6.0-windows10.0.19041 or later. (I've yet to understood why just net6.0-windows doesn't work—I don't know what it is about Rx that requires the v10.0.19041 SDK or later. But if you don't specify that version or later, you won't get the WPF features.) But once you've set that as your TFM, it will pick up the version of Rx that includes WPF functionality.

This works for .NET 6.0 and .NET 7.0 when using Rx v5.0. So I don't think you needed the change you've asked for. (And now that we have made this change to enable us to build net6.0 targets, I don't think it will actually change anything for you—you still need a Windows-specific TFM with a suitably recent SDK version number to pick up the WPF bits).

Be aware that we're planning to change how this works in Rx 7.0. We are moving UI-framework-specific elements (such as DispatcherScheduler) out into UI-framework-specific libraries, because having them all merged into the mainSystem.Reactive` libraries has been causing all sorts of problems on modern versions of .NET.

glen-nicol commented 1 year ago

I think the problem with the current setup is that targeting net6.0-windows10.0.19041 is not tenable to anyone who wants to support older versions of windows. And the previous versions had msbuild properties available to get the same result without changing the TFM.

I am happy to hear the plan is to separate the UI specific parts into separate packages. I think that will solve this in a better way.

idg10 commented 1 year ago

A couple of things to be aware of regarding the net6.0-windows10.0.19041 moniker:

  1. it doesn't technically require you to be running a version of Windows that offers the 10.0.19041 API surface area or later.
  2. every version of Windows that is currently still in support provides the 10.0.19041 API surface area

Regarding 1, the precise meaning of net6.0-windows10.0.19041 isn't "I need to be running on a version of Windows that offers at least that recent an API version". It's "I want to be able to try to access features from that API version." It is possible to build your app in such a way that it is able to deal with some API features not being present.

You do that by specifying a minimum OS version. This can be lower than the version in the TFM. https://learn.microsoft.com/en-us/dotnet/standard/frameworks#support-older-os-versions describes this. So your TFM could specify 10.0.19041, but your minimum OS version could be much lower, meaning that you'll still be able to run on older versions, it's just that you need to be prepared for some OS features not to be there.

Regarding 2, support for the SDK 10.0.19041 API surface area came in with Windows 10 2004. The version before that, 1909, was the last version not to offer the full 10.0.19041 API surface area, and that officially went out of support in November 2021, although it appeared to receive security updates up until May 2022. So you're off the edge of the map if you're supporting older versions than that, although in principle you can still use Rx's WPF or Windows Forms features using the mechanism described for 1 above.

We aren't intending to test future Rx release on out-of-support versions of Windows, so if you're in a situation where you absolutely have to target something so old it doesn't have the 10.0.19041 API, I can't guarantee Rx 7.0 will definitely work for you. (Perhaps as part of this work I will learn why my predecessors decided to stipulate 10.0.19041 as a minimum API version, and might find that I need to continue to do so even after separating WPF and Windows Forms into their own packages.)