Retarget the test project to net8.0 so the test suite runs on current SDKs

[ntdatt812]

Summary

The test project targets netcoreapp3.1, which went out of support in December 2022. No currently shipping .NET SDK can run it, so half the test matrix aborts before a single test executes:

Testhost process ... exited with error: You must install or update .NET to run this application.
Framework: 'Microsoft.NETCore.App', version '3.1.0' (x64)
The following frameworks were found:
  8.0.28 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  10.0.9 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Test Run Aborted.

On Windows the net461 leg still runs, so you get 684 passing tests and an aborted run. On Linux or macOS neither leg runs, which means dotnet test gives a contributor nothing at all.

After this change both legs run:

Passed! - Failed: 0, Passed: 684, Skipped: 0, Total: 684 - CommandLine.Tests.dll (net8.0)
Passed! - Failed: 0, Passed: 684, Skipped: 0, Total: 684 - CommandLine.Tests.dll (net462)

Same 684 tests, no test code touched.

What changed

One file, tests/CommandLine.Tests/CommandLine.Tests.csproj:

• netcoreapp3.1 → net8.0
• net461 → net462
• Microsoft.NET.Test.Sdk 16.0.1 → 17.11.1, xunit 2.4.1 → 2.9.2, xunit.runner.visualstudio 2.4.1 → 2.8.2
• the PLATFORM_DOTNET condition now keys off "not .NET Framework" instead of "starts with netcoreapp"

Notes on the two less obvious bits

Why net462. xunit.runner.visualstudio 2.8.2 has a floor of net462, so the old runner has to stay or the framework leg has to move up. net461 has been out of support since April 2022 and net462 is the lowest supported .NET Framework, so moving up seemed better than pinning the runner.

This does not reduce what gets covered. The library still targets net461 and the net462 test assembly resolves that exact output — I compared the hashes to be sure:

tests/.../bin/Debug/net462/CommandLine.dll   fbfed138d1f2ab93d344ba48c778cce6
src/.../bin/Debug/net461/CommandLine.dll     fbfed138d1f2ab93d344ba48c778cce6

The net8.0 leg picks up netstandard2.0, which is what everyone on modern .NET actually consumes and what previously had no runnable coverage at all.

The PLATFORM_DOTNET condition. It was TargetFramework.StartsWith('netcoreapp'), so renaming the TFM to net8.0 would have silently stopped defining it and dropped a using in OptionMapperTests.cs. Keying off !StartsWith('net4') keeps it defined for every non-Framework target.

Scope

I deliberately left src/CommandLine/CommandLine.csproj alone — it still targets netstandard2.0;net40;net45;net461, so this changes nothing for consumers. #786 asks for the library itself to move, which is a separate conversation with real compatibility implications; this is just the part that stops contributors from running the tests.

One thing I noticed while looking around: the AppVeyor project has no builds recorded, so the badge in the README may not reflect anything current. If it would help, I'm happy to follow up with a small GitHub Actions workflow that builds and runs both legs on pull requests.

[ntdatt812]

Correcting my own note at the bottom of the description: AppVeyor did pick this up and the build passed, so disregard that remark about the project having no builds recorded — I had been looking at branch builds rather than PR builds.

That also answers the question I could not check locally: the VS2019 image ships an SDK new enough for the net8.0 leg, so the retarget builds and both test legs run green on your CI.

https://ci.appveyor.com/project/commandlineparser/commandline/builds/54531788