Migrated an existing project from Nuke.* → Fallout.* on nuget.org — recipe

[ChrisonSimtian]

Migrated an existing project from Nuke.* → Fallout.* on nuget.org — recipe

I migrated ErpForFactoryGames (a .NET 10 Blazor + Aspire app with a small NUKE pipeline) from the private Nuke.* packages on the ChrisonSimtian GitHub Packages feed to the new public Fallout.* packages on nuget.org. Posting the steps here so the next consumer who tries this can copy/paste, and so #37 has a real-world recipe to point at.

For my project this was a Path-B migration in the language of docs/rebrand-plan.md: clean cutover, not the Nuke.* shim bridge.

Starting point

• build/_build.csproj referenced Nuke.Common 10.2.1 from a private GitHub Packages feed (the old ChrisonSimtian/nuke fork).
• nuget.config had a packageSourceMapping routing Nuke.* to that feed, plus GITHUB_TOKEN plumbing in CI and build.ps1 to satisfy GitHub Packages' "auth-required even for public packages" rule.
• build/Build.cs + build/Configuration.cs used Nuke.* namespaces and derived from NukeBuild.

Steps that worked

1. build/_build.csproj — swap the PackageReference:

   - <PackageReference Include="Nuke.Common" Version="10.2.1" />
   + <PackageReference Include="Fallout.Common" Version="10.2.15" />

2. nuget.config — drop the Nuke.* mapping. Keep the GitHub Packages feed only if it still serves other packages (mine still serves SatisfactorySaveNet). Otherwise delete the source entirely:

     <packageSource key="github-chrisonsimtian">
       <package pattern="SatisfactorySaveNet" />
       <package pattern="SatisfactorySaveNet.*" />
   -   <package pattern="Nuke.*" />
     </packageSource>

3. build/Build.cs + build/Configuration.cs — strict 1:1 rename per the rebrand plan:

   - using Nuke.Common;
   - using Nuke.Common.CI.GitHubActions;
   - using Nuke.Common.IO;
   - using Nuke.Common.ProjectModel;
   - using Nuke.Common.Tooling;
   - using Nuke.Common.Tools.DotNet;
   - using static Nuke.Common.Tools.DotNet.DotNetTasks;
   + using Fallout.Common;
   + using Fallout.Common.CI.GitHubActions;
   + using Fallout.Common.IO;
   + using Fallout.Common.ProjectModel;
   + using Fallout.Common.Tooling;
   + using Fallout.Common.Tools.DotNet;
   + using static Fallout.Common.Tools.DotNet.DotNetTasks;
   ...
   - class Build : NukeBuild
   + class Build : FalloutBuild

4. Build once — ./build.ps1 Compile. The source generator regenerates .nuke/build.schema.json automatically (the NukeBuild definition becomes FalloutBuild); commit the regenerated schema.

That's the whole change. Compile + restore green on first try, no surprises.

Things worth calling out for the migration guide

• MSBuild properties keep their Nuke* names. <NukeRootDirectory>, <NukeScriptDirectory>, <NukeTelemetryVersion> were not renamed — the rebrand plan covers namespaces + assemblies only, and Fallout's own build/_build.csproj still uses them. I left mine unchanged and the build was happy. Might be worth a one-liner in the guide so people don't tidy them up out of misplaced consistency.

• .nuke/build.schema.json regenerates. The diff after Compile was just NukeBuild → FalloutBuild in two spots. Mildly surprising to see a "generated" file in the diff — flagging in case the guide wants to mention "commit the regenerated schema, it's expected".

• NoWarn=NU5104 stayed relevant. I'd added it to suppress the SemVer-prerelease noise from the old fork's -beta01 packages. The current Fallout.Common 10.2.15 is a stable SemVer, so I could probably drop it — left it for now in case future prereleases reintroduce the warning.

• Auth deletion. Once Nuke.* was the only thing pulling from the private feed, dropping the package-source mapping let me delete a chunk of GITHUB_TOKEN plumbing in my CI workflow and dev README. Big quality-of-life win — could be worth highlighting in the guide as the "ROI" of the migration for projects that were only using GH Packages for NUKE.

Documentation on my side

I wrote this up as ADR-0021 for traceability. Happy to link from the migration guide once #37 lands.

Thanks for the rebrand — the 1:1 mapping made this completely mechanical, which is exactly what you'd want.

[ChrisonSimtian]

Follow-up after merging the migration on my side — a couple of extra notes for the guide that surfaced post-recipe:

• CI passed clean on first push. Lint (dotnet format), build + test, migration-drift, and Postgres-smoke jobs all went green with no extra changes. Confirms the namespace rename really is the whole story for a typical consumer.
• .nuke/ directory stays. I kept it as-is and Fallout's source generator regenerated build.schema.json in place. Worth a one-liner in the guide: existing .nuke/ directories don't need to be renamed (and Fallout's own repo carries both .nuke/ and .fallout/, so this isn't an accident).
• Bootstrap scripts need zero changes. build.ps1 / build.sh / build.cmd reference build/_build.csproj by path, not by NUKE assemblies, so they survive the migration untouched. Useful to call out — I checked them and didn't have to.
• User-defined types that derive from Fallout base classes also migrate via the same using swap. My Configuration : Enumeration (using Nuke.Common.Tooling → Fallout.Common.Tooling) is a tiny example, but it confirms the bridge works at the consumer-extension layer too, not just for direct NukeBuild derivation.

PR on my side: ErpForFactoryGames#184 (merged). ADR-0021 link in the original post above stays valid.