Discuss: Drop support for older platforms

[clairernovotny]

In general, Ix and Rx (though mostly Rx) have support for a wide variety of platforms, including win8, wp8, wpa81, and net45. This leads to tremendous extra complexity as we seek to include features in later platforms.

In some cases, the surface area was necessarily different as some types/features weren't available in "down-level" platforms, leading to a complex assembly versioning strategy in #205.

The question becomes, at what point can we drop support for < NET Standard 1.4? That would put us in a prime position to have a single binary that works across all target platforms with extra functionality for UWP or Xamarin to support specific UI threading concepts.

My proposal would be for vNext (Rx/Ix 4.0), to raise the minimum requirements to .NET Framework version to 4.6.1, UWP and Xamarin. This is in-line with the .NET Standard 2.0 supported platforms here: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Pros:

• Remove virtually all cross-compiling
• Would no longer require the strict assembly versioning of Implement assembly version strategy #205 since api surface area would be the same

Cons:

• Some customers targeting older .NET versions or Win81/Windows Phone 8.1 won't be able to update. Existing 3.x version would be the end-of-the-road for those platforms

[clairernovotny]

/cc @anpete @natemcmaster for the EF take on this

[natemcmaster]

EF Core (and ASP.NET Core in general) supports net451 and netstandard1.3. I'm not aware of any plans to lift that to higher framework versions in the 1.x timeframe.

[clairernovotny]

@natemcmaster so if we cross-compile to net451 and use netstandard1.3 as a baseline for .NET Standard, would that work? I.e., we can drop all the win8-level platforms w/o impact to you?

[natemcmaster]

we can drop all the win8-level platforms w/o impact to you?

Correct. Microsoft.EntityFrameworkCore doesn't target win8-level platforms.

[grahamehorner]

I have a lot of clients that are restricted to the .NET 4.0 framework as they have many 1000's of Windows XP systems which need supporting; removing support for things like RX would have a major impact on these clients; while I agree RX should move forward it should be in a major that supports older platforms like Windows XP and if RX is to move to core or a cross platform implementation this is infact a new product and not a new version.

[JohanLarsson]

@grahamehorner they can still use the current version of rx on their 1000's of XP systems no?

[JohanLarsson]

I have not followed net core/standard etc closely, not at all in fact. Will WPF be ported to / be compatible with NET Standard 1.4?

[shiftkey]

@grahamehorner

if RX is to move to core or a cross platform implementation this is infact a new product and not a new version.

What you propose is the opposite of what we did with the Rx and Ix 3.0 release, and we did this after months of discussions with various parts of Microsoft to ensure we did things smoothly. It was not a decision made lightly, and while we did talk about forking the project that was something talked about with caution, as we wanted to avoid unnecessary fragmentation.

Dropping support for platforms over time that are no longer supported by the upstream authors is part of the natural cycle of software things. Whether the owners of the platforms are Microsoft, Node, or Apple, we need to draw a line in the sand. We're not removing the existing versions of libraries from NuGet, for those who want to continue to use those releases.

Did you know that Rx and Ix has the ability to build against .NET 3.5? And Silverlight 5? And Windows Phone 7? We're carrying around this sort of accumulated #ifdef complexity and it really hurts the ability for move along because certain platforms lack certain features that they're never going to get. Simplifying the number of platforms we target means the codebase becomes less intimidating, and I'd love to make it easier for others to help improve Rx and Ix.

Personally, I'm fine with using major versions as the opportunity to introduce major architectural changes as long as we call these out long in advance, just like this. We've learned a lot from feedback about the 3.0 release that we've incorporated into 3.1.

@JohanLarsson

Will WPF be ported to / be compatible with NET Standard 1.4?

There are various technical reasons why WPF cannot be ported to .NET Core - but that's not something I have control over, so I won't speak for that team in any official capacity. You'd have to look at projects like Avalonia if you want a cross-platform UI framework that targets .NET Standard.

[JohanLarsson]

@shiftkey My question is not about x-plat UI. I'm wondering if dropping support means that WPF-stuff will not be able to use future versions of Rx.

[shiftkey]

I'm wondering if dropping support means that WPF-stuff will not be able to use future versions of Rx.

The WPF dependency is isolated to the System.Reactive.Windows.Threading package, which depends on WindowsBase and System.Windows that ship in the .NET Framework. Same thing with System.Reactive.Windows.Forms (it also has System.Windows.Forms, obviously).

I'm not quite across all the .NET Standard 2.0 changes, but if .NET Framework 4.6.1 is a valid implementation of .NET Standard 2.0, then these platform-specific libraries can target net461 and only include .NET Framework dependencies. I'm not sure about the UWP story - @onovotny can fact-check me here.

Just had a look at the stats on NuGet - in it's lifetime Rx-WPF (the old package name for 2.x) has 86k downloads, and System.Reactive.Windows.Threading already has 28k downloads, despite only being out for a few months - so that's cool!

[clairernovotny]

Basically, it's like this... we'll be shipping a net451 and a netstandard1.3 version as that's what EF requires. What that means is that any framework that's equal-to-or-greater-than any of those will work.

You can see the table here: https://docs.microsoft.com/en-us/dotnet/articles/standard/library#net-platforms-support

That means that UWP, Xamarin, NET 4.5.1, etc are all fully supported.

For WinRT-specific optimizations, we would create a UWP-specific package for those.

[NN---]

@shiftkey You say I can build latest Rx for .NET 3.5?
How I do it? And why there is no NuGet then ?
We are stuck with Rx 1:(

[shiftkey]

@NN---

You say I can build latest Rx for .NET 3.5?

Not the latest source - this was more of an interesting footnote that I came across. While the 2.x branch was able to be compiled against .NET 3.5, I don't believe it was intended to be supported.

How I do it?

Roughly speaking, you can do this:

• git checkout v2.2.5
• Open Rx.NET\Source\Rx.sln
• Change the active solution configuration to Debug35 or Release35

You may see some build errors about missing targeting packs - I'll leave resolving those as an exercise for the reader.

And why there is no NuGet then ?

Supporting all the various versions of .NET is a non-trivial amount of work, even for something as specific as Rx.NET. Deprecating support for platforms once their usage falls below a certain threshold is often necessary, and I highly recommend upgrading to get the benefits that are there in recent updates to .NET.

[NN---]

I can try 2.2.5.
Unfortunately it is product requirement since .NET 3.5 is still supported by MS.

[shiftkey]

@NN---

Unfortunately it is product requirement since .NET 3.5 is still supported by MS.

I have no understanding about why you're still on .NET 3.5, but due to having a limited amount of time to work on this project I have no intentions to add support for .NET 3.5. Apologies.

[NN---]

Very simple. Windows 7 has .NET 3.5 and doesn't require any additional installations.

[mattpodwysocki]

@NN--- unfortunately, as we are looking forward, we cannot keep .NET 3.5 alive for various reasons including the lack of the standardized TPL which was introduced in .NET 4.0 and we use Task extensively moving forward. We are sorry for the inconvenience.

[NN---]

@martinwoodward I understand.
I am trying to compile 2.5.5 from source and it gives me a lot of build error even for .NET 4.5 ..
I run 'build.bat'.
Should I do something else ?
Thanks.

[clairernovotny]

This has been done for Rx in the v4.0 alpha's on the MyGet feed