Cherry-pick the Fallout.Common.ProjectModel migration path onto 10.4 - #590
Merged
ChrisonSimtian merged 4 commits intoJul 28, 2026
Conversation
The fallout-migrate CLI rewriter only swapped the `Nuke.` prefix, so a NUKE-era `using Nuke.Common.ProjectModel;` landed on the now-dead `Fallout.Common.ProjectModel` namespace — the solution types moved to `Fallout.Solutions` in Fallout-build#257. Add a rule mapping both the Nuke and interim Fallout `Common.ProjectModel` namespaces to `Fallout.Solutions`, run before the generic prefix swap so each reference migrates in a single edit. Mirrors the analyzer codefix from Fallout-build#253, which never reached the CLI tool. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 8da363e)
The solution types shipped under `Fallout.Common.ProjectModel` in Fallout 11.0.1–11.0.12 and moved to `Fallout.Solutions` in 11.0.13 (Fallout-build#257), breaking that upgrade with no shim. Restore the common entry-point pattern (`[Solution] readonly Solution Solution;`) by mirroring `Solution` + `SolutionAttribute` back into the old namespace inside Fallout.Common. Shallow by design — deep graph navigation, GenerateProjects source-gen, and binary compat still require `fallout-migrate` — matching the ceiling of the generated `Nuke.Common.ProjectModel` shim. A new compile-time consumer sentinel (Fallout.Consumer.ProjectModelShim, in fallout.slnx) fails CI if the shim regresses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 63ac171)
… shim generator The new Fallout.Common.ProjectModel.Solution/SolutionAttribute entry-point shims are public types under Fallout.Common, so the Nuke.Common shim's 'Fallout.Common -> Nuke.Common' generator rule swept them up and emitted Nuke.Common.ProjectModel.Solution — which the 'Fallout.Solutions -> Nuke.Common.ProjectModel' rule also emits from the canonical type. Two partial declarations with different base classes → CS0263/CS0111, failing Compile. Give ShimAllPublicTypesUnder an ExceptNamespacePrefixes option and exclude Fallout.Common.ProjectModel from the broad Fallout.Common rule. Those types relocated to Fallout.Solutions in v11 and are shimmed by the dedicated rule; the Fallout.Common.ProjectModel re-exports are a Fallout-side grace shim that must not be re-shimmed into Nuke. Regenerated the affected Verify snapshots (attribute surface + the solution generator picking up the new sentinel consumer project Fallout-build#528 adds). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 26280ad)
CodeRewriter.Rewrite had a single caller (RewriteCsFilesStep). Move its regex fields and Rewrite method directly into the step and delete the now-empty class. Rename the spec file/class to match. Mirrors the CsprojRewriter fold, so a migration step owns the rewrite rules for its artifact type instead of delegating them to a free-floating static class in Steps/. Raised in review on Fallout-build#528. No behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 9fb8800)
ChrisonSimtian
added
bug
ChrisonSimtian
marked this pull request as ready for review
July 28, 2026 22:41
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-picks #528 onto the 10.4 release line. Non-breaking / additive.
Why
10.4.0-rc.4breaks consumers upgrading from10.3.x. The solution types moved fromFallout.Common.ProjectModeltoFallout.Solutions, with no shim on this branch:Reported against rc.4 on a real consumer repo. Shipping 10.4.0 GA as-is makes every
[Solution] readonly Solution Solution;build fail on upgrade.Changes
Four commits, cherry-picked with
-x, no conflicts:Common.ProjectModel→Fallout.Solutionsin the CLI migrator —fallout-migrateonly replaced theNuke.prefix, rewritingusing Nuke.Common.ProjectModel;to the now-unusedFallout.Common.ProjectModelinstead of the real namespace. Both the old and interim namespaces now map toFallout.Solutionsin one edit.Fallout.Common.ProjectModelentry-point transition shim —SolutionandSolutionAttributemirrored back so the canonical consumer pattern keeps compiling without runningfallout-migratefirst.Nuke.Commonshim generator.CodeRewriterintoRewriteCsFilesStep— included soFallout.Migratestays byte-identical tomain, keeping later cherry-picks clean.All six touched source files are now identical to
main.Limits
The shim is shallow by design — an entry-point grace period, not a full alias. Navigating the graph still hands back canonical
Fallout.Solutions.*types, andGenerateProjectskeys off the canonical attribute.fallout-migrateremains the complete path. Same ceiling as the existingNuke.Common.ProjectModelshim.Verification
fallout.slnxbuild: 0 errors.GitRepositoryWorktreeSpecsfailures that reproduce identically on the unmodified base commit — they assert on the git remote identifier and only fail on a fork clone whose branch tracksupstream. Not related to this change.Fallout.Migrate.Specs38/38,Fallout.SourceGenerators.Specs9/9.Nuke.Consumer(shim-collision guard) and the newFallout.Consumer.ProjectModelShim, which is exactly the reported pattern.Follow-ups
version.jsonto10.4.0-rc.5before tagging — deliberately not in this PR, since a second cherry-pick (Keep publishing the CLI as Fallout.GlobalTool #581) is queued for the same RC and the counter should move once.