Proposal: Drop .NET Standard 2.1 target

[paulirwin]

Is there an existing issue for this?

• I have searched the existing issues

Task description

As part of implementing #1039, it dawned on me. I'd like to propose that we drop the .NET Standard 2.1 (netstandard2.1) target. I don't think it makes much sense going into 2025 with the limited amount of currently-supported implementations that support it that aren't already covered by our netstandard2.0 or net8.0 targets.

Docs: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1

As a reminder, no version of .NET Framework or UWP supports netstandard2.1, so those can either use our net462 target or netstandard2.0. Xamarin is now out of support as well, along with .NET (Core) 3.0-7.0.

The only currently supported .NET implementations that support netstandard2.1 in that list are:

• .NET 8 (we already have a net8.0 target for this)
• .NET 9 (would use our net8.0 target)
• Mono 6.4+
• Unity 2021.2, maybe?

The first two are covered by our net8.0 target and thus don't apply. (If we added a net9.0 target, it also wouldn't use the netstandard2.1 build.) The latter two presumably have no issues running netstandard2.0, and Mono 6.4 is listed on the netstandard2.0 tab as well. As far as I can tell, Unity releases get 2 years of LTS support, so 2021.2 should be out of support by now anyways, if I understand correctly. But again, even then, it should be able to use netstandard2.0.

So, basically, we'd be keeping this target around for some slight possible performance optimizations for... people running apps on Mono. (And again, I'm referring to Mono specifically here, not Xamarin running on Mono, which is out of support.)

This target was added in 0482957 in 2019, and I don't see any issues about justifications for why it was added. I assume it was added as an attempt to have just one target to support both Xamarin and .NET Core 3.x-5 primarily, since the next major target that was added was net6.0.

For posterity, the Lucene.NET compilation features that .NET Standard 2.1 supports that 2.0 does not are:

• FEATURE_ARRAY_FILL
• FEATURE_CONDITIONALWEAKTABLE_ENUMERATOR
• FEATURE_CONDITIONALWEAKTABLE_ADDORUPDATE
• FEATURE_NUMBER_PARSE_READONLYSPAN
• FEATURE_STREAM_READ_SPAN
• FEATURE_STRINGBUILDER_APPEND_READONLYSPAN
• FEATURE_QUEUE_TRYDEQUEUE_TRYPEEK

As we get closer to a 4.8.0 final release, I think we have to determine if this is worth supporting for however many years into the future we have to support it, just for already-older versions of Mono and Unity. Microsoft themselves recommend skipping netstandard2.1 if you can.

Dropping .NET Standard 2.1 would have several benefits:

• One less target to build for and faster local builds (at least until we add another target)
• We would not need to run tests against .NET 6 (as of Drop net6.0 target and use net6.0 to run netstandard2.1 tests, #1020 #1039; .NET 5 before this) to test netstandard2.1, reducing test time and resources
• We therefore would also not need to install the unsupported .NET 6 SDK in the builds
• We could simplify some of the logic for the feature constants

Given the tradeoffs, is it still worth supporting netstandard2.1 as a target today?

[NightOwl888]

Given the fact that

• FEATURE_CONDITIONALWEAKTABLE_ENUMERATOR
• FEATURE_CONDITIONALWEAKTABLE_ADDORUPDATE

are pretty crucial to ensuring the GC cleans up properly and also impact performance quite a bit, I wouldn't wish netstandard2.0 on anybody who doesn't absolutely require it. If I had to choose a target to eliminate, it would be netstandard2.0, since it has the least number of optimizations and the most hacks in it.

The only real impacts of doing so would be:

• Dropping UWP support completely
• Requiring higher versions of most other platforms that are still in support
• Breaking compatibility with any library that depends on the netstarndard2.0 target so they don't have to multi-target (but we should discourage this practice because of the performance degradation on netstandard2.0 vs net462 or net8.0)

If using NuGet, the netstandard2.0 target will never be installed in a .NET Framework application, since it will prefer net462.

The System.Memory APIs in that list are also important for performance (and this gap is likely to grow as we add support for System.Memory, since netstandard2.1 supports it much better than older platforms).

• FEATURE_NUMBER_PARSE_READONLYSPAN
• FEATURE_STREAM_READ_SPAN
• FEATURE_STRINGBUILDER_APPEND_READONLYSPAN

[paulirwin]

So should we extend this issue to dropping netstandard2.0 as well? I'd be open to that.

Requiring higher versions of most other platforms that are still in support

What do you mean by this? As you point out, which is a really good point, .NET Framework isn't going to use our netstandard2.0 build anyways. UWP was deprecated in 2021, and is only expected to receive bug fixes, so I assume you're not referring to that. Xamarin is no longer in support, and the supported versions of .NET (8 and 9) will use our net8.0 build. So the only question mark would be Unity and Mono.

[NightOwl888]

Well, dropping them both is something to consider. Most of the issues we have with testing .NET Standard are because as you stated, there are not very many platforms where they are still supported. It certainly would make testing easier if we didn't have to apply SetTargetFramework to override the target under test with a platform that is no longer officially supported. Not to mention, if we transition to testing NuGet packages instead of publishing binaries it will mean we don't need to pack extra NuGet packages that only have the target under test in it just so it will be resolved with the right target under test. PackageReference doesn't have an equivalent to SetTargetFramework, so that is the best we can do.

That being said, I am not sure about dropping support for Unity just yet. They are still working on supporting .NET Core. According to ChatGPT there have only been a few previews released, but so far no RTM release. So, keeping a netstandard2.1 target until that transition is complete is probably a good idea.

As for Mono, I don't think it is such a big concern as it is being phased out in favor of .NET Core in most cases, but keeping netstandard2.1 would also allow those who are still in the process of transitioning time to finish their migration.

Requiring higher versions of most other platforms that are still in support

What do you mean by this? As you point out, which is a really good point, .NET Framework isn't going to use our netstandard2.0 build anyways. UWP was deprecated in 2021, and is only expected to receive bug fixes, so I assume you're not referring to that. Xamarin is no longer in support, and the supported versions of .NET (8 and 9) will use our net8.0 build. So the only question mark would be Unity and Mono.

Yes, as you astutely pointed out, all that are really left are Unity and Mono. Modern versions of these are both supported on netstandard2.1, which makes the supported audience for netstandard2.0 effectively zero. That is, other than the convenience of having a single target framework for libraries that depend on us (which comes at a significant performance cost) and any stragglers that are still supporting UWP.

[paulirwin]

It looks like Unity won't get .NET 8+ until a 2025 beta and (presumably) a 2026+ Unity 7 release: https://discussions.unity.com/t/coreclr-and-net-modernization-unite-2024/1519272

It would certainly be frustrating if we're keeping this target around and there are no Unity users using it. It would be nice if NuGet could somehow give us usage numbers per platform. To the community reading this, is anyone out there using the netstandard2.1 target?

Also, I split out dropping .NET Standard 2.0 as #1041.