Drop netcoreapp2.1 targets

[rprouse]

It is out of support and generating build warnings.

C:\Program Files\dotnet\sdk\5.0.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.EolTargetFrameworks.targets(28,5): warning NETSDK1138: The target framework 'netcoreapp2.1' is out of supp
ort 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. [C:\Src\NUnit\nunit\src\NUnitFra
mework\mock-assembly\mock-assembly.csproj]

[stevenaw]

We should consider backporting this to v3.13 as well. The test projects also target netcoreapp2.1 there

[CharliePoole]

Dropping it from your runners is a reasonable decision but if you drop it from your acceptance tests, then you are unable to verify that things still work. So second-level tests like mock-assembly may still need to target the out-of-support runtimes.

And, of course, it's trivial to suppress the warning.

[manfred-brands]

you are unable to verify that things still work
Isn't that what 'out of support' means?

What if a new feature doesn't work on netcoreapp2.1, what are we supposed to do then?

[CharliePoole]

Well, actually, "out of support" can mean lots of things. Microsoft does a pretty good job of defining it for themselves. If NUnit is no longer supporting netcoreapp2.1, then I think you might want to define what you mean by that. Maybe it means, you can no longer write tests that target netcoreapp2.1. Or maybe you can write them, but they will always run (via nunitlite) under netcoreapp3.1. If you can still write them (which you can't stop users from doing) then I think you ought to test that they run as you plan.

Of course, some people may say "It's up to Microsoft to make sure they run" but NUnit has always been a bit more rigorous than that.

If you want to be rigorous, then you need to test that it works - either manually or as part of ci. To do that you need some second-level test assemblies (similar to mock-assembly), which are built for the target you are no longer supporting.

If it were me, I'd have versions of mock-assembly (for example) for net20, netcoreapp2.1 and even netcoreapp1.1, which I'd run as post-packaging integration tests.

[CharliePoole]

FYI you can either suppress the message using nowarn or eliminate the end-of-life check for all a project's targets using <CheckEolTargetFramework>false</CheckEolTargetFramework>.

[manfred-brands]

Thanks, that 2nd option is much cleaner. Updated the PR #3988

[rprouse]

.NET is releasing revisions so often now that we are making it tough for developers to contribute to NUnit. Do compile and run the tests, you need to install too many SDKs and runtimes, so I'd like to see us mirroring the support cycle for the runtimes.

[CharliePoole]

That's cool... but MS defines (kind of) what they mean by support. Not sure we (either framework or console) do that clearly.

For MS it's basically, use at your own risk. Sometimes, for business reasons, companies have to take that risk and it seems to me we should specify how we support (or do not support) such folks. I was aiming for "You can write tests targeting an eol runtime, and we have verified that you can run them using NUnit, although not under that same runtime." I'm doing that for testcentric, which doesn't have built-in agents for net20, or netcore < 3.1. So i run package tests against mock assembly and check the results.

Yes, I do see that it requires folks to have those runtimes installed and that's less good. I'm working on taking them out of the VS build while keeping them conditionally in the ci build. This has saved me a few surprises already, btw.

I suppose one approach is to take them all out of the build and only put them back in once there's a conditional build mechanism set up.