build: Fallout 10.4 across the repo group, pinned exactly (#321)

* build: pin Fallout to 10.4.0 exactly

Bumps the build system from Fallout.Common 10.3.5 to 10.4.0, and pins it with
bracket notation.

The pin matters more than the bump. A bare "10.4.0" in NuGet is a *minimum*,
not an exact version, so restore is free to satisfy it with anything higher --
and it did: this repo was silently resolving Fallout.Common 11.0.8, a major
version nobody chose, while the csproj claimed 10.3.5. [10.4.0] turns a missing
package into an error instead of an unannounced upgrade, which is the whole
point of pinning a build system.

Side effect worth noting: the build now restores with zero warnings, down from
twelve. The drifted 11.0.8 dependency tree was pulling
System.Security.Cryptography.Xml 10.0.6, which carries five high-severity
advisories; 10.4.0 does not.

Verified: restores 10.4.0, compiles clean, and the target graph runs --
Fallout Execution Engine 10.4.0.15.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* build: pin Fallout to 11.0.8, not 10.4.0

Reverses the version half of the previous commit. The pin stays; the number
was wrong, and CI proved it.

What actually happened: this file said "10.3.5", but a bare version in NuGet is
a *minimum*, not a match — so every build here has quietly been resolving
Fallout.Common 11.0.8. "Bumping" to 10.4.0 was therefore a downgrade from what
CI was really running, which is why a version bump could break a green build.

10.4.0 hangs the Test target. It waits on the test process, which does not exit
promptly in this repo, then kills it: the build fails with exit 143 roughly 30
seconds after every test has already passed (41 passed, 5 skipped). Reproduced
locally as well as on CI, where it also leaves testhost processes alive for
minutes -- one reached 20 GB before exiting.

11.0.18 is not the answer either: it moved Fallout.Common.ProjectModel, so
Build.cs no longer compiles. That is worth doing deliberately, not as a
side effect of a version bump.

So: [11.0.8], which is what CI has in fact been green on for months, now
recorded explicitly instead of arrived at by accident. The other three repos in
the group are pinned to the same version.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* build: back to Fallout 10.4.0, and fix the Test-target hang properly

Reverts the wrong turn in the previous commit. I moved the group to 11.0.8
because CI had been green on it -- without checking that the entire 11.x line
is UNLISTED on nuget.org. Restore still reaches unlisted versions when
satisfying a minimum, so "green on 11.0.8" meant CI had been silently building
on a withdrawn package. That is the bug, not the baseline. 10.4.0 is the latest
listed release (2026-08-07); the search index carries no 11.x at all.

So: [10.4.0], which was the ask all along, and the exact pin is what stops a
bare minimum from wandering into withdrawn territory again.

That leaves the actual problem the first attempt ran into -- 10.4.0 failing the
Test target with exit 143 about thirty seconds after every test had passed.

Running the same `dotnet test` command directly, with Fallout out of the
picture, exits fine. So the tests are not what hangs. Fallout waits for the
child's output streams to reach EOF, and MSBuild's reusable worker nodes and
build server outlive `dotnet test` while still holding the inherited stdout
handle. EOF never arrives, Fallout waits out its grace period, kills the
process, and surfaces 143.

MSBUILDDISABLENODEREUSE=1 and DOTNET_CLI_USE_MSBUILD_SERVER=0 stop those
daemons outliving the command, so the pipes close and the process is reaped.
build.sh already passes -nodeReuse:false for the same reason when building the
build project itself; this extends it to the test run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: ChrisonSimtian

build/Build.cs

@@ -156,6 +156,13 @@ class Build : FalloutBuild
             // Web.UiTests namespace, so !~ Web.UiTests matches them all. The UiTests
             // project still compiles but no tests run, so the AspireAppFixture (which
             // calls Microsoft.Playwright.Program.Main on init) never executes.
+            //
+            // The two node-reuse variables are not cosmetic. Fallout waits for the
+            // child's output streams to reach EOF, and MSBuild's reusable worker
+            // nodes and build server outlive `dotnet test` while still holding the
+            // inherited stdout handle — so EOF never arrives, Fallout waits out its
+            // grace period and kills the build with exit 143, long after every test
+            // has passed. Disabling the daemons lets the pipes close.
             DotNetTest(s => s
                 .SetProjectFile(Solution)
                 .SetConfiguration(Configuration)
@@ -164,6 +171,8 @@ class Build : FalloutBuild
                 .SetResultsDirectory(TestResultsDirectory)
                 .AddLoggers("trx;LogFilePrefix=test")
                 .AddLoggers("console;verbosity=normal")
+                .SetProcessEnvironmentVariable("MSBUILDDISABLENODEREUSE", "1")
+                .SetProcessEnvironmentVariable("DOTNET_CLI_USE_MSBUILD_SERVER", "0")
                 .SetFilter("FullyQualifiedName!~Web.UiTests"));
             Log.Information("TRX results written to {Dir} (Web.UiTests excluded — run `./build.sh Test` locally to include them)", TestResultsDirectory);
         });

build/_build.csproj

@@ -17,8 +17,23 @@
   </PropertyGroup>
 
   <ItemGroup>
-    <!-- Fallout is the hard-fork successor to NUKE; published to nuget.org (ADR-0021). -->
-    <PackageReference Include="Fallout.Common" Version="10.3.5" />
+    <!--
+      Fallout is the hard-fork successor to NUKE; published to nuget.org (ADR-0021).
+
+      Pinned exactly with bracket notation, and the pin is the point. A bare
+      version in NuGet is a *minimum*, not a match, so this file said "10.3.5"
+      while every build — local and CI — was quietly resolving 11.0.8.
+
+      That was not a harmless drift: the entire 11.x line is **unlisted** on
+      nuget.org. Restore still reaches unlisted versions when satisfying a
+      minimum, so CI was silently building on a withdrawn package. 10.4.0 is the
+      latest listed release (published 2026-08-07); the search index carries no
+      11.x at all.
+
+      An exact pin is what stops a minimum from wandering into withdrawn
+      territory.
+    -->
+    <PackageReference Include="Fallout.Common" Version="[10.4.0]" />
   </ItemGroup>
 
   <ItemGroup>