Dropping support for .NET Standard 1.x and 2.0

[CXuesong]

WCL users,

Thanks for supporting this library during the past 4 years!

For now, WCL is supporting .NET Standard platform version as low as 1.1. While this provides great compatibility, as time moves on , this hinders the adoptation of new features provided by C# / .NET (such as the built-in IAsyncEnumerable interface since .NET Core 3.0), and I don't want to keep maintaining more and more #if compiler directives 🌚

I'd like to make this step a bit aggressive. Since the last Core implementation of .NET Standard 2.0 is reaching to its EOS on 2021-08-21, I'm planning to drop support on .NET Standard 1.1 ~ 2.0, and focus the support on .NET Standard 2.1. This means since the next major update of WCL,

• .NET Framework will no longer be supported, You won't be able to author .NET Framework applications or libraries based on later versions of WCL.
• You will need to target your .NET Core application to .NET Core 3.1 (latest LTS) or above, including .NET 5.
• You will need to target your .NET library at .NET Standard 2.1, or .NET Core 3.0 or above,
• For .NET Standard 2.1 implementations on other platforms, see .NET implementation support.

Since this is a breaking change, I'll release the next version (after targeting platform change) as v0.8.0 or v1.0.0. You can still authoring your applications on older versions of WCL, but you won't be able to receive WCL feature updates on those platforms not supported by .NET Standard 2.1.

If you have any comments regarding to this proposal, please let me know. Thank you!

[CXuesong]

cc
(Sorry for spamming. Please unsubscribe this issue if you'd like not to receive further updates.)

Recent PR authors
@mormegil-cz
@ntrpnr
@FaFre

Recent issue authors
@HarelM
@BrunoBlanes
@mthomason12
@tigerpaw28
@Torvin
@DavidWBrooks
@Uziel302
@zstadler
@TheOnlyBrian

Other WCL dependents
@mavaddat
@daniel-centore
@yooakim
@tigerpaw28
@hargitomi97
@AnnoDesigner
@magicalmysticalcat
@werdes
@AntiTcb
@Redblueflame
@stjohann
@Alenael
@urbanecm
@ketura
@PlanetCal
@Pajdzik
@tjdurant
@Speyd3r
@Silic0nS0ldier
@mtcairneyleeming

[Redblueflame]

Thanks for the heads up!

[HarelM]

Does it support .net 5? I'm looking to upgrade soon and want to know if I should expect upgrade issues...

[CXuesong]

Does it support .net 5? I'm looking to upgrade soon and want to know if I should expect upgrade issues...

@HarelM .NET 5 is a later version of .NET Core 3, so it's supported.

[BrunoBlanes]

Great choice!

[Silic0nS0ldier]

Sounds good to me, however keep in mind that .NET Standard 2.1 is not supported by UWP at time of writing. dotnet/standard#1567 Of course everything will (in time) be moved onto .NET 5, part of project reunion if I'm not mistaken. Not like old versions of this library will be going anywhere so safe enough to ignore IMO.

[CXuesong]

@Silic0nS0ldier Yeah I'm aware of that. But now it looks like .NET Standard 2.1 is not going to be supported by UWP in future shrug

Let me instead check the possibility for multi-targeting, as long as they support async streams.

[BrunoBlanes]

Are they really not going to support UWP in .NET Standard 2.1? I thought they'd move UWP forward with NET 6.

[CXuesong]

@BrunoBlanes I'm afraid so. dotnet/standard#1567 (comment) says

UWP will eventually have full .NET 5 or 6 support (so no .NET Standard 2.1) and an early preview will be available next month.

And a sad story that the latest UWP SDK does not support async streams, which is the primary reason driving me dropping support for earlier SDK versions.

So it looks I'll have to (prematurely) drop UWP support until UWP can run on .NET 6. (I was not even aware of there could be downstream UWP apps using this library… That's just, wow, too cool to think…)

[BrunoBlanes]

No nooo, it is coming!

[BrunoBlanes]

It is already possible to make UWP apps run in .NET 5, though they still target the .NET Standard 2.0 and this is currently not officially supported, but according to the Community Call, it will be.
They even show a demo of it working natively, though they wouldn't give us a timeline.

You don't think AsyncStreams will be supported along with .NET 5?

[CXuesong]

@BrunoBlanes async stream is supported on .NET Standard 2.1 & .NET (Core) 3 / 5. But UWP is not supporting .NET Standard 2.1 for now.

UWP on .NET 5 is technically doable but it looks not easy to achieve: microsoft/WindowsAppSDK#105, so I'd like to take this with a grain of salt.

That being said, I'll keep the current plan unless there are reports on certain UWP app not able to consume WikiClientLibrary...

Perhaps later I can try referencing WCL on an ordinary UWP app and see what happens, but either way that shouldn't affect my current decision 😂

[BrunoBlanes]

Yeah ok, I guess we might also learn more on .NET Conf: Focus on Windows.

[hawkerm]

Happened to stumble upon this thread while searching for other things. The Microsoft.Bcl.AsyncInterfaces NuGet package should provide the IAsyncEnumerable type to .NET Standard 2.0, if that was the main reason for dropping support down to .NET Standard 2.0. Not sure if anyone would use this from Unity, but keeping UWP and .NET Framework support could be useful for a while longer still.

There are a couple of blogs about this topic for compatibility here and here.

FYI @Sergio0694

[CXuesong]

@hawkerm thanks for your suggestion! The primary reason I drop support on .NET Standard 2.0 is for an out-of-box nullable reference type annotation support. And I'd like to use this chance to reduce the platform-specific conditional directives.

If I were to support .NET Standard 2.0, there will be some attributes to declare (e.g., MaybeNullWhenAttribute) and some CS8630 error to suppress. Perhaps I'll revisit the possibility to support .NET Standard 2.0, but I don't suppose that will make much difference -- unless someone brings up the need to consume WCL on .NET Framework, .NET Core 1/2, or UWP (before .NET 6 comes out).

I assume most of the consumers of WCL are working with MediaWiki bots, or data collecting projects, both of which are relatively small in scale and easy to migrate SDK versions. The notable exception is IsraelHikingMap/Site, but they are already on .NET Core 3.1 LTS.

Thus I deem this library is not cursed by legacy code, and will make use of the chance to be aggressive, constantly trying something new… well until someone consuming the library put a brake on it 😁

[HarelM]

No need to worry about israelhikingmap, I plan to migrate to .net 5 once I get a chance to switch to a linux server running docker which will allow easy future .net upgrades...
Regardless, libraries that use an old .net version can still use old versions that exist on NuGet...