chore: migrate to .slnx and enable central package management

[jeremydmiller]

Groundwork for the xunit 3 migration, but independently useful. Two commits, both infrastructure-only.

1. jasperfx.sln → jasperfx.slnx

Solution folders (src, TestHarnesses, Widgets) survive migration, so the Nuke [Solution(GenerateProjects = true)] accessors Build.cs depends on (Solution.src.*, Solution.TestHarnesses.*) keep their generated names.

Two companion changes are required, not optional:

• .nuke/parameters.json pinned the solution by filename. Every Nuke target fails at startup without updating it.
• global.json pinned sdk.version: 9.0.100. .slnx restore needs 9.0.200+, so the old floor can no longer build the repo. rollForward: latestMajor happened to mask this on CI (which also installs 10.0.x), but relying on roll-forward to clear a hard floor shouldn't stay implicit — now pinned to 10.0.100.

2. Central package management

All 47 package versions move into Directory.Packages.props. Three things here are load-bearing:

Per-TFM versions survive as conditional PackageVersion groups — Directory.Packages.props is evaluated per inner build, so $(TargetFramework) is available. JasperFx and JasperFx.RuntimeCompiler each had two near-identical conditional ItemGroups that collapse to one now that the version was the only difference.

Roslyn cannot collapse to one version. Three consumers want three different answers:

Consumer	Version	Why
JasperFx.RuntimeCompiler	[4.14.0,6.0.0) net9 / 5.0.0 net10	ships runtime compilation, tracks the SDK — takes the central default
JasperFx.SourceGenerator	4.3.0 (VersionOverride)	netstandard2.0; a generator built against 4.14+ won't load in an older consumer's compiler
JasperFx.Events.SourceGenerator	4.8.0 (VersionOverride)	same
both generator test projects	4.8.0 (VersionOverride)	host Roslyn in-process to drive the generator under test

Verified with dotnet list package after the change that all four still resolve exactly as before. The unconditional Roslyn default also has to exist so the netstandard2.0 projects resolve at all — neither TFM condition applies to them, so without it they hit NU1010.

build/ opts out via its own Directory.Packages.props. It already isolates itself from repo MSBuild via Directory.Build.props/.targets, but CPM discovery does not follow that isolation — NuGet walks up independently — so Build.csproj's inline Nuke.Common version would otherwise fail NU1008.

The one real behavior change

Five versions were drifting in EventStoreTests alone and are now unified up to match the rest of the repo:

xunit 2.9.2→2.9.3 · xunit.runner.visualstudio 2.9.2→3.0.0 · NSubstitute 5.1.0→5.3.0 · Shouldly 4.2.1→4.3.0 · Microsoft.Extensions.TimeProvider.Testing 9.0.0→9.7.0

That suite is the thing to watch in review. It passes.

Verification

Full suite green on both target frameworks:

Suite	Tests
CoreTests	475
CodegenTests	419
CommandLineTests	295
EventTests	648
EventStoreTests	72
CodegenTests.FSharp	1

Plus smoke-test-aot and the CLI smoke commands.

Incidental finding, not addressed here: JasperFx.SourceGenerator.Tests (19), JasperFx.Events.SourceGenerator.Tests (26), and JasperFx.Aspire.Tests (51) are in the solution but in no Nuke target and no CI step — 96 tests that compile and never run. All three pass locally. Follow-up PR.

🤖 Generated with Claude Code