Should we stop testing on .NET Core 2.1 and 3.1?

[stakx]

On recent builds, we get a bunch of out-of-support warnings for .NET Core 2.1 and 3.1:

warning NETSDK1138: The target framework 'netcoreapp2.1' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.
warning NETSDK1138: The target framework 'netcoreapp3.1' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

For .NET Core 2.1, we additionally get security vulnerability warnings:

warning NU1903: Package 'Microsoft.NETCore.App' 2.1.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-2xjx-v99w-gqf3
warning NU1902: Package 'Microsoft.NETCore.App' 2.1.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-3gp9-h8hw-pxpw
warning NU1903: Package 'Microsoft.NETCore.App' 2.1.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-3w5p-jhp5-c29q
warning NU1902: Package 'Microsoft.NETCore.App' 2.1.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-5633-f33j-c6f7
warning NU1903: Package 'Microsoft.NETCore.App' 2.1.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-6px8-22w5-w334
warning NU1903: Package 'Microsoft.NETCore.App' 2.1.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-g5vf-38cp-4px9
warning NU1902: Package 'Microsoft.NETCore.App' 2.1.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-vgwq-hfqc-58wv
warning NU1902: Package 'Microsoft.NETCore.App' 2.1.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g

Simply suppressing those warnings doesn't seem right, I think we should first decide whether or not we want to continue supporting those out-of-support frameworks at all.

See also:

• The last discussion we had on this topic: Stop testing for .NET Core 2.1/3.1 and update some nuget packages #660
• .NET and .NET Core Support Policy: https://aka.ms/dotnet-core-support

[Romfos]

+1 to drop it

also make sense:

1. Drop .NET Standard 2.1 from tfm list
2. Replace .NET 6 to .NET 8 in tfm list

[jonorossi]

Simply suppressing those warnings doesn't seem right, I think we should first decide whether or not we want to continue supporting those out-of-support frameworks at all.

Completely agree. We explicitly build for .NET 6 so I'd test for .NET 6. .NET Standard support in the library is just a bonus.

Replace .NET 6 to .NET 8 in tfm list

If we're talking a major release, then this seems logical with .NET 6 support ending in 2 months. I can't make comment about .NET Standard versions without looking into why we added 2.1.

[stakx]

I can't make comment about .NET Standard versions without looking into why we added 2.1.

I'd have to go check, too, but IIRC:

• We have .NET Standard 2.1 to cover .NET Core versions 3.x and 5.x (and .NET Standard 2.0 to cover .NET Core 2.x).
• Also, because most popular downstream libraries (FakeItEasy, Moq, NSubstitute, etc.) target the same .NET Standard TFMs.

If we want to play nice with the .NET ecosystem, we may want to consider coordinating future supported TFMs with these other projects.

[Romfos]

I can't make comment about .NET Standard versions without looking into why we added 2.1.

I'd have to go check, too, but IIRC:

• We have .NET Standard 2.1 to cover .NET Core versions 3.x and 5.x (and .NET Standard 2.0 to cover .NET Core 2.x).
• Also, because most popular downstream libraries (FakeItEasy, Moq, NSubstitute, etc.) target the same .NET Standard TFMs.

If we want to play nice with the .NET ecosystem, we may want to consider coordinating future supported TFMs with these other projects.

Drop .NET Standard 2.1 should not affect ecosystem because we still have .NET Standard 2.0

.NET Standard 2.1 was just an small optimization (have more built-in api => less external deps) for runtimes that already deprecated (.NET Core 3, Xamarin, .NET 5)

Do we have a custom support policy or we just follow official Microsoft support policy?

Today all new libraries from dotnet team support:

1. .NET 8+
2. .NET Framework 4.6.2+
3. .NET Standard 2.0

Also you will see a warning\error for .NET Standard 2.0 on older runtimes that MS do not test for them and recommend to update to supported runtimes

[Romfos]

Some intersting facts about .NET Standard 2.0

State of .NET Standard 2.0 in 2024:

.NET implementation	Version support	Status	Comment
.NET and .NET Core	2.0, 2.1, 2.2, 3.0, 3.1, 5.0, 6.0, 7.0, 8.0, 9.0	Supported	Support .NET 8+ by ms
.NET Framework	4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1	Supported	Support .NET Framework 4.6.2+ by ms
Mono	5.4, 6.4	Deprecated
Xamarin.iOS	10.14, 12.16	Deprecated	.NET MAUI is a replacement for .NET 6+
Xamarin.Mac	3.8, 5.16	Deprecated	.NET MAUI is a replacement for .NET 6+
Xamarin.Android	8.0, 10.0	Deprecated	.NET MAUI is a replacement for .NET 6+
Universal Windows Platform	10.0.16299	Deprecated	UWP for .NET 9+ is a replacement
Unity	2018.1	Supported	.NET 8 migration planned for next release
Windows Phone	n\a	Deprecated
Windows Phone Silverlight	n\a	Deprecated

My private opinion:

1. Target: .NET 8, .NET Framework 4.6.2, .NET Standard 2.0
2. Test for: .NET Framework, .NET 8, .NET 9
3. Use the same versions for external dependencies. (now .NET 6 version have dependency with higher version then net standard)
4. Don't use legacy\deprecated dependencies. Try to use the latest .NET LTS versions for MS packages
5. Cleary say that we don't support and don't test on legacy runtimes

[stakx]

Oh, that reminds me, .NET Standard 2.1 has an API missing in 2.0 that is beneficial for DynamicProxy. So perhaps we should keep 2.1, not 2.0 (if we keep targeting .NET Standard at all).

[Romfos]

Oh, that reminds me, .NET Standard 2.1 has an API missing in 2.0 that is beneficial for DynamicProxy. So perhaps we should keep 2.1, not 2.0 (if we keep targeting .NET Standard at all).

We definitely cannot drop now NS 2.0, because, as you described here, it will affect libraries that depends on castle core lib

We can drop 2.1 because libs (FakeItEasy, Moq, NSubstitute, etc.) with NS 2.1 tfm will automatically pick NS 2.0 version.
by this reason drop 2.1 is safe, without disrupting ecosystem

If we want also drop NS 2.0, I agree, we need to align it with other libraries and maybe make a buffer in 6+ month for them to adopt