Switch to .NET 6

[rdeago]

I announced a possible switch of EmbedIO to .NET 6 in #546:

You probably saw this coming. 😄

With .NET Framework on life support, both .NET Core 3.1 and.NET 5 scheduled for phase-out this year, and .NET Standard being just a way to support both .NET and .NET Framework, this should be a no-brainer.

If you have a use case that requires staying on .NET Standard 2.0, please explain it in a comment.

I don't plan to do the switch in v4.0-preview.1, but it may come in a later preview, unless someone presents a decent case against it.

EDIT: SWAN already made the leap to .NET

While updating dependencies, I discovered that SWAN version 4 (now called Unosquare.Swan.Lite4 on NuGet) is not compatible with .NET Standard 2.0 any longer; instead, you have to target at least .NET 5 to use it. I'm staying on Swan.Lite v3.1.0 for now; as soon as there's some feedback on whether to switch EmbedIO to .NET 6, I'll know which version of SWAN to use.

Although which SWAN version to use is no more a concern, there are some features introduced with recent versions of .NET (Core) and the C# compiler that are missing from .NET Standard 2.0 and can do a sizable difference in EmbedIO's reliability, performance, and code quality. Just from the top of my mind:

• IAsyncDisposable (we can finally write cleanup code that makes sense - re: WebServer, WebSocket, etc.);
• Caller argument expressions (no more nameof when validating arguments);
• Init-only setters (immutable configuration without the hassle of correctly subclassing ConfiguredObject).

There are even more features that can be beneficial in the near future: think for example WebSocketBase using a source generator for routing, instead of building and compiling LINQ expression at run time.

Comments and criticisms are welcome, as usual.

[michael-hawker]

.NET Standard 2.0 is still pivotal to the ecosystem for support for .NET Framework, UWP, Xamarin Forms, and Unity developers.

Moving to .NET 6 for building the project makes sense still of course and allows you to make use of C# 10 features of course, but that doesn't mean the underlying library needs to be moved up as well.

It's going to be a while before developers and the applications they write can adopt the latest .NET still. .NET Standard still helps to ensure the widest audience can use your library. See this blog here, which outlines this well..

Many newer runtime features are available still for .NET Standard 2.0 by changing the language version and polyfills. This article here has some info by @Sergio0694. We're doing this in the Community Toolkit's as well.

• IAsyncDisposable is for instance available as a NuGet package.
• Caller argument expressions need a simple polyfill.
• Init-only setters are the same as well.

Source generators work wherever you need them as well, they were designed with .NET Standard 2.0 in mind still.

[rdeago]

Hello @michael-hawker, thanks a lot for sharing your thoughts as well as some precious info.

You make quite a compelling argument in favor of .NET Standard 2.0. I've also looked into Community Toolkit and it seems to provide quite a few goodies EmbedIO can use, so thanks for that too.

So, the new plan could be to triple-target .NET Standard 2.0, .NET Standard 2.1, and .NET 6. Would this fit existing runtimes optimally, or is there something I overlooked?

[michael-hawker]

@Sergio0694 has a bit more experience with how the multi-targeting works from the .NET Community Toolkit side, he may be able to call out any more specifics or things to watch out for.

Though my understanding is basically that as long as the consumer of the package is running on the newer runtime they get all the optimized benefits that runtime provides automatically.

The main bits you have to worry about as the author is just setting up your csproj files and some conditionals to properly exclude the polyfill bits that bring the newer features to the .NET Standard 2.0 target. Though there's a lot of examples on how that all works in the .NET Community Toolkit.