Drop net8.0 and net9.0, ship net10.0 only, at the November 2026 support deadline

[solrevdev]

Why

.NET 8 (LTS) and .NET 9 (STS) both reach end of support on 10 November 2026. After that date neither gets security fixes, so seedfolder should stop building and shipping against them.

.NET 10 is LTS and is supported until November 2028.

Do this work on or shortly before the November deadline, not earlier. seedfolder ships as a .NET global tool, and the target frameworks decide who can install it. Anyone still on the .NET 8 SDK loses the ability to run dotnet tool install -g solrevdev.seedfolder the moment we drop net8.0, so there is no reason to cut them off early.

What to change

• src/solrevdev.seedfolder.csproj line 5: replace the TargetFrameworks list with a single TargetFramework of net10.0.
• .github/workflows/ci.yml lines 52-55: drop 8.0.x and 9.0.x from setup-dotnet, leaving 10.0.x.
• tests/integration-test.sh: about 20 hardcoded --framework net8.0 arguments. With a single target framework the flag can go entirely, since dotnet run no longer needs disambiguating.
• tests/integration-test.ps1: same, about 20 more.
• CLAUDE.md and AGENTS.md line 7: both say the project targets net8.0, net9.0 and net10.0.
• .github/copilot-instructions.md line 22: already wrong today. It claims the project targets net8.0;net9.0, missing net10.0, and describes .NET 9 as having 18-month support. Fix it while you are here.
• Add <RollForward>Major</RollForward> to the csproj. See the roll-forward section below for why.
• Bump <Version> in the csproj. Dropping target frameworks is a breaking change for anyone on an older SDK, so a minor bump at minimum, and consider 2.0.0.

Note that README.md already uses --framework net10.0 in its examples, so it needs no change.

global.json: not needed, do not add one

There is no global.json in this repo, and none should be added as part of this work.

The intuition runs the wrong way here, so it is worth stating plainly. Per the matching rules, when no global.json is found the highest installed SDK is used, which is already equivalent to rollForward: latestMajor. Having no file is the most permissive setting available.

Adding one can therefore only narrow SDK selection, never widen it. Worse, a global.json with a version and no rollForward defaults to patch, which is far stricter. That file would break the build the moment .NET 10 is uninstalled, which is the exact failure people add a global.json hoping to avoid.

It is also aimed at the wrong half of the problem. global.json selects the SDK used to build this repo. It has no effect on anyone running the installed tool, which is where the real risk lives. See the next section.

No snippet is given here on purpose, so there is nothing to paste in by mistake. The fix for this issue is the RollForward MSBuild property, not a new file.

The real roll-forward risk: installed users, not the build

global.json only chooses the SDK when building this repo. It has no effect on people who have installed seedfolder from NuGet. That is a separate mechanism, and it is where the "user upgraded to .NET 11 and no longer has .NET 10" scenario actually bites.

.NET tools are framework-dependent apps. Per Troubleshoot .NET tool usage issues, runtime roll-forward does not cross major version boundaries by default. Once seedfolder is net10.0 only, a user whose package manager has moved them to .NET 11 with no .NET 10 runtime present will find the tool simply fails to start.

The fix is one MSBuild property in src/solrevdev.seedfolder.csproj:

<PropertyGroup>
 <RollForward>Major</RollForward>
</PropertyGroup>

That writes the policy into the tool's runtimeconfig.json, so it runs on .NET 11 and later when no .NET 10 runtime is installed. Please add this as part of this work, or sooner. It matters more once we are single-targeted, but it helps today too.

• Add <RollForward>Major</RollForward> to the csproj and confirm it lands in the packed runtimeconfig.json.

This has been tested, not just read about

Verified in a container rather than taken from the docs. The test builds seedfolder targeting net8.0 and runs it in mcr.microsoft.com/dotnet/sdk:10.0, which carries only the .NET 10 runtime. A tool asking for an absent major with only a higher major present is the same shape as a net10.0 tool on a future .NET 11 machine, so it reproduces the November problem today.

Case	runtimeconfig.json	Result
A. No RollForward	no rollForward key	Failed, exit 150
B. <RollForward>Major</RollForward>	"rollForward": "Major"	Worked
C. Case A installed with --allow-roll-forward	no rollForward key	Worked

Case A failed like this:

You must install or update .NET to run this application.

App: /root/.dotnet/tools/seedfolder
Framework: 'Microsoft.NETCore.App', version '8.0.0' (arm64)

The following frameworks were found:
 10.0.10 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

That is the exact message a user would hit after their package manager moved them off the targeted runtime.

Case B was checked properly, not just with --version. The installed tool seeded a full node project on the .NET 10-only box and wrote every expected file. Note the roll-forward crossed two majors, 8 to 10, without complaint.

Reproduce it with docker run --rm -v "$PWD:/work" -w /work mcr.microsoft.com/dotnet/sdk:10.0 bash, then single-target net8.0, pack, dotnet tool install -g --add-source, and run.

The user-side escape hatch

Case C shows users on the .NET 9 SDK or later can rescue themselves, but they have to know the flag exists, so this is not a substitute for fixing it in the csproj:

dotnet tool install -g solrevdev.seedfolder --allow-roll-forward

Validation

The usual Release sequence from CLAUDE.md:

dotnet build solrevdev.seedfolder.sln --configuration Release
./tests/integration-test.sh
dotnet pack solrevdev.seedfolder.sln -c Release --no-build --include-source --include-symbols

Also worth doing, since the test scripts are the thing most likely to break:

• Run tests/integration-test.ps1 under pwsh as well. CI only runs the shell script, so the PowerShell one drifts without anyone noticing.
• After packing, confirm the .nupkg contains only the net10.0 folder.
• Install the packed tool locally and run it once. See build/test-local.sh, and check what it does to your global tools before running it.

Resources

• Releases and support for .NET — the support table and the LTS/STS policy
• .NET Support Policy — authoritative end-of-support dates
• global.json overview — full rollForward value list with examples
• Target frameworks in SDK-style projects — TargetFramework versus TargetFrameworks
• .NET tools — how a tool's target framework affects who can install it