Split tool wrappers out of Fallout.Common into per-tool projects + NuGet packages #72

Problem

Fallout.Common is a kitchen sink. It contains:

• Framework basics (FalloutBuild, Target, parameter injection, etc.).
• ~70 tool wrappers under src/Fallout.Common/Tools/<Tool>/: DotNet, MSBuild, Docker, Helm, Kubernetes, AzureKeyVault, Xunit, ReportGenerator, GitVersion, Paket, Boots, Chocolatey, … most of which a typical consumer never touches.

Every consumer pays for every tool — bigger compile times, bigger restore graph, transitive deps for tools they don't use.

Goal

Make Fallout.Common a clean base library:

• Each tool wrapper → its own project + NuGet package.
• Consumers add a PackageReference per tool they use.
• Third parties can ship Foo.Fallout.Tools.<Bar> packages on the same architecture without touching this repo.
• We keep maintaining a baseline set of officially supported tools.

Naming proposal

Fallout.Tools.<Tool> (e.g. Fallout.Tools.DotNet, Fallout.Tools.Docker, Fallout.Tools.Helm). Mirrors the existing Fallout.Utilities.IO.Compression / .Globbing style.

Layout:

src/
  Fallout.Common/                       # framework basics only
  Fallout.Tools.DotNet/
    Fallout.Tools.DotNet.csproj
    DotNet.json
    DotNet.Generated.cs                 # regenerated
    DotNetTasks.cs                      # hand-written extras
  Fallout.Tools.Docker/
    ...

Mechanical plan

1. New project per tool — references Fallout.Common (or a narrower base if we slice further). Targets net8.0;net9.0;net10.0.
2. Move src/Fallout.Common/Tools/<Tool>/ → src/Fallout.Tools.<Tool>/, preserving the .json/.Generated.cs pairing.
3. Update the generator: per-project namespaceProvider: x => $"Fallout.Tools.{x.Name}" instead of Fallout.Common.Tools.{x.Name}. Namespace flattens — Fallout.Common.Tools.DotNet.DotNetTasks → Fallout.Tools.DotNet.DotNetTasks.
4. Update fallout.slnx + Directory.Packages.props.
5. Add per-tool tests under tests/Fallout.Tools.<Tool>.Tests/.
6. Roll into the release pipeline so each tool packs separately.

Migration impact

• Breaking for consumers. Add <PackageReference Include="Fallout.Tools.DotNet" /> and update using Fallout.Common.Tools.DotNet; → using Fallout.Tools.DotNet;. Both mechanical — fit for fallout-migrate.
• Breaking for shim consumers. The Nuke.Common shim must either re-export the tool surface from Nuke.Common.Tools.<Tool> namespaces (more wrapper code) or split into matching Nuke.Tools.<Tool> shim packages.
• Belongs in 11.0, aligned with the existing FALLOUT001/002/003 deprecation sunsets.

Carve-outs to leave in Fallout.Common

Framework-coupled tools probably stay:

• Tools/Git/ — used by [GitRepository] injection.
• Tools/GitHub/ — used by ICreateGitHubRelease.
• Tools/GitVersion/ — used by IHazGitVersion.
• Tools/MSBuild/ — used by ProjectModel.

Borderline:

• Tools/DotNet/ — used by IPublish, IPack, IRestore, ITest. Probably stays.
• Tools/NuGet/, Tools/Paket/ — adjacent to IPublish. Maybe stays.

Everything else (Docker, Helm, Kubernetes, Xunit, ReportGenerator, AzureKeyVault, …) splits out.

Why filed in Backlog

A significant breaking change with no immediate release pressure. Worth doing alongside other 11.0-aligned breaks (legacy Nuke* MSBuild prop/env-var removal). Listed here so demand can accumulate; promote to a milestone when planning 11.0.

Done when

• Decision recorded on which tools stay (framework-coupled list above) vs split out
• One tool extracted as proof of concept (Fallout.Tools.Docker or similar) — exercises generator, packaging, release pipeline, consumer story
• Remaining tools migrated (mechanical, after the proof)
• fallout-migrate rewrites the namespace + adds per-tool <PackageReference> entries
• Migration guide entry ([P5] Write NUKE → Fallout migration guide #37) covers the split
• Nuke.Tools.<X> shim packages, or Nuke.Common shim updated to re-export from the new namespaces
• Release pipeline ships Fallout.Tools.<X> packages alongside Fallout.Common