Lift the netstandard2.0 floor off the tooling stack via an out-of-process MSBuild bridge

[ChrisonSimtian]

⚠️ Breaking change — Fallout.Tooling / Fallout.Tooling.Generator drop netstandard2.0 (now net8.0;net10.0 and net10.0) and Fallout.MSBuildTasks drops net472. A consumer referencing those assemblies directly from a netstandard2.0/net472 project must move to net8+/net10. The MSBuild integration's behaviour is preserved for VS2019/2022 via a new out-of-process bridge (below).

Implements Lever 2 of #441 — frees the tooling stack from the ns2.0 floor so Fallout.Core (ns2.1) can absorb Configure<T> / AbsolutePath / the tool contracts (de-static Phase 2b/2c/2e). Design recorded in ADR-0009 (in this PR).

How

netstandard2.0 is the only TFM that can't consume Fallout.Core (ns2.1), and the floor came solely from Fallout.MSBuildTasks's net472 target (loaded by full-framework VS MSBuild) referencing Fallout.Tooling.

• Task logic extracted to a net10 Fallout.MSBuildTasks.Engine.
• Core MSBuild (dotnet/SDK): in-process net10 task — the hot path, keeps ALC isolation.
• Full-framework MSBuild (VS2019/2022): a thin net472 ToolTask bridge that shells out to a standalone net10 worker (Fallout.MSBuildTasks.Worker) — zero Fallout deps, so Tooling no longer needs ns2.0.
• .targets selects by $(MSBuildRuntimeType); packaged into build\netcore (task) / build\netfx (bridge + worker).
• Fallout.Tooling keeps a net8 flavour for Fallout.ProjectModel's down-level targets — net8 consumes ns2.1, so the floor is still lifted.

The bridge is time-boxed: delete it once VS2026's .NET MSBuild can load net10 tasks in-process.

Verification ⚠️ (why this is a draft)

• ✅ Full solution build + entire test suite green; the worker is smoke-tested out-of-process.
• ❌ Not yet verified: the consumer task path + Pack output, and the net472 VS full-framework bridge — these aren't exercised on non-Windows or by this repo's dogfood (which runs FalloutTasksEnabled=False). Needs a Windows + VS + Pack smoke test before un-drafting.

🤖 Generated with Claude Code

[ChrisonSimtian]

Bridge smoke test (Windows + VS2019/2022 full-framework MSBuild): the Full path fails — STJ binding.

Ran the consumer codegen path on this branch (commit 7220ab5) across all three runtimes:

• dotnet / SDK MSBuild (Core, in-proc net10 task): ✅ generates valid output
• VS2022 MSBuild.exe (Full, net472 bridge): ❌
• VS2019 MSBuild.exe (Full, net472 bridge): ❌ (identical)

The bridge throws before it ever spawns the worker:

error MSB6003: System.IO.FileNotFoundException: Could not load file or assembly
'System.Text.Json, Version=10.0.0.0, ... PublicKeyToken=cc7b13ffcd2ddd51'
  at Fallout.MSBuildTasks.Protocol.WorkerJson.Serialize[T]
  at CodeGenerationTask.BuildRequestJson() -> WorkerBridgeTask.GenerateCommandLineCommands()

Root cause: Fallout.MSBuildTasks.Protocol serializes with System.Text.Json. The packaged STJ is assembly version 10.0.0.8; the code references 10.0.0.0. The bridge runs in-process inside .NET-Framework MSBuild.exe, where fusion needs an exact version or a binding redirect — neither is present (and a Bridge.dll.config redirect isn't honored for an in-proc task; only the host MSBuild.exe.config is). On .NET Core, roll-forward hides this for the in-proc task and the worker, so only Full breaks.

This contradicts ADR-0009 §3 ("the bridge references only Microsoft.Build.* + the BCL — zero Fallout dependencies"): the Protocol's STJ dependency reintroduces exactly the version-sensitive in-proc dependency the bridge design set out to avoid.

Fix (pushed): WorkerJson now uses the in-box DataContractJsonSerializer (System.Runtime.Serialization); STJ PackageReference dropped from the Protocol project. STJ no longer ships in build/netfx. Re-ran all three drivers: Core, VS2019, VS2022 now produce byte-identical generated output.

Repro runbook: docs/agents/msbuild-bridge-smoke-test.md.

[ChrisonSimtian]

TLDR; in order to break up the whole god-class cluster, I need to break a few things open, this being one of them.
Isolated this, broke out the legacy stuff into a standalone-bridge to service windows vs2019 and windows 2022 (macos vs2022 uses netcore already Oo)

Also, interesting read on VS support:
https://learn.microsoft.com/en-us/visualstudio/releases/2026/servicing-vs#support-for-older-versions
VS2026: End of Support = 2028
VS2022: End of Support = 2032 (!)
VS2019: End of Support = 2029 (!)

Classic Microsoft move... I'd say with that in mind: we do a bridge. We keep it side-by-side as long as we can but drop it latest 2032 (oh god thats in 6 years from now!)

[ChrisonSimtian]

This also needs some testing. So please be my guest, run it against all sorts of pre 2026 VS instances :-)

[ChrisonSimtian]

@dennisdoomen not quite tidy but have a look and let me know what you think.
I want to lift this into its own little library to unlock us doing a lift & shift for the rest of fallout. Plus this whole thing is going away with vs2026 on windows (already gone on vs2022 for macos funnily enough, I assume rider and vscode never had this problem because they're not based on a 100yr old codebase ...)