Cherry-pick the Fallout.GlobalTool package id onto 10.4 - #593
Merged
ChrisonSimtian merged 4 commits intoJul 28, 2026
Merged
Conversation
The dotnet-tool package id had been changed to Fallout.GlobalTools (plural)
ahead of first release. Revert it: Fallout.GlobalTool is the id the entire
10.2.x/10.3.x install base already has pinned (52 published versions, latest
10.3.49), so continuing to publish under it means nobody migrates and no id
has to be unlisted. Assembly/namespace stay Fallout.Cli; command stays
`fallout`.
- Fallout.Cli.csproj: <PackageId>Fallout.GlobalTool</PackageId>, with a comment
recording why it deliberately doesn't match the assembly name.
- templates/dotnet-tools.json + BuildScaffolder comments: `fallout :setup`
writes a `fallout.globaltool` pin into consumer repos again.
- UpdateNotificationAttribute: in-tool prompt says `dotnet tool update
Fallout.GlobalTool -g`.
- build/Build.cs: the Install target installed `Solution.Fallout_Cli.Name`
("Fallout.Cli"), which never matched the packed nupkg id. Point it at a new
GlobalToolPackageId constant instead.
Docs swept repo-wide for the plural id: README install + note, CONTRIBUTING,
introduction, 01-installation, 02-setup, 03-execution, github-actions,
rebrand-plan. docs/migration/from-globaltool-to-cli.md deleted — it documented
a GlobalTool -> Cli rename that is now explicitly never happening, and was
already draft:true with no inbound links.
Left alone: .config/dotnet-tools.json still pins fallout.cli 10.3.45. That is
the repo's own dogfood pin and flipping it needs a published Fallout.GlobalTool
build newer than 10.3.49; doing it here would regress `dotnet tool restore`.
Verified: pack produces Fallout.GlobalTool.*.nupkg; Fallout.Cli.Specs 47/47.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit e6e787c)
Review feedback on Fallout-build#581: the Install target shouldn't carry yet another hardcoded copy of the package id. Fallout.ProjectModel already exposes MSBuild property access on the solution model, so walk the object path instead: Solution.Fallout_Cli.GetProperty("PackageId") // -> Fallout.GlobalTool Drops the GlobalToolPackageId constant added in the previous commit. The csproj is now the single source of truth for the id, so changing it later touches one file. No new API was needed — ProjectExtensions.GetProperty (src/Fallout.ProjectModel) has covered this since the NUKE days, and the same MSBuild-evaluation path is already exercised by this build at Build.cs:98 via GetTargetFrameworks(). Verified end-to-end against fallout.slnx: GetProperty("PackageId") on the Fallout.Cli project returns "Fallout.GlobalTool". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit cef0b37)
The "UPDATE RECOMMENDED FROM 5.1.0" header was hardcoded in NUKE 9885956 (March 2021) and never updated since, so it named a version no Fallout consumer has ever run. The header still earns its place — it gives the numbered steps context in a server-build warning — so only the version reference goes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit e735790)
docs/rebrand-plan.md is being removed — it describes a rename that has already landed and reads to AI tools as a live plan needing maintenance. The reason this PackageId deliberately diverges from the assembly name belongs with the package-id-as-consumer-contract discussion in Fallout-build#582. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 9abde1d)
ChrisonSimtian
added
bug
ChrisonSimtian
marked this pull request as ready for review
July 28, 2026 22:41
This was referenced Jul 29, 2026
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 #581 onto the 10.4 release line, so 10.4.0 GA continues the
Fallout.GlobalToolsequence from 10.3.49. Non-breaking on the GA line.Why
release/v10.4currently packs the CLI asFallout.GlobalTools(plural), an id introduced after the 10.3 line and shipped exactly once, in10.4.0-rc.4.Fallout.GlobalTool(singular) has 52 published versions on nuget.org (10.2.12 → 10.3.49) — that's what the entire install base has pinned.Tagging GA off this branch as-is would strand every existing consumer on a dead id. Staying on the singular id means no consumer migrates, no id gets unlisted, and no migration guide is needed. Blast radius of the revert is rc.4 testers only.
Changes
Four commits, cherry-picked with
-x, no conflicts:Fallout.Cli.csproj—<PackageId>Fallout.GlobalTool</PackageId>, with a comment recording why the package id deliberately doesn't match the assembly name.templates/dotnet-tools.json+BuildScaffolder—fallout :setupwrites afallout.globaltoolpin into consumer repos again.UpdateNotificationAttribute— in-tool prompt saysdotnet tool update Fallout.GlobalTool -g; also drops a stale NUKE-era version string.build/Build.cs— reads the tool's package id off the csproj instead of hardcoding it. Fixes theInstalltarget, which usedSolution.Fallout_Cli.Name("Fallout.Cli") and never matched the packed nupkg id.falloutcommand. Deletesdocs/migration/from-globaltool-to-cli.md(documented a rename that is now explicitly never happening).Assembly and namespace stay
Fallout.Cli; the command staysfallout. All touched files are byte-identical tomain.Verification
dotnet pack src/Fallout.Cli→Fallout.GlobalTool.10.4.0-rc.4.nupkg(the.g<commit>suffix seen locally is only because the topic branch isn't a public release ref; it stamps clean onrelease/v10.4).fallout.slnxbuild: 0 errors.build/_build.csprojcompiles.Fallout.Cli.Specs47/47; full test run otherwise green.GitRepositoryWorktreeSpecsfailures reproduce identically on the unmodified base commit — they assert on the git remote identifier and only fail on a fork clone whose branch tracksupstream. Unrelated; the equivalent run on Cherry-pick the Fallout.Common.ProjectModel migration path onto 10.4 #590 was green on all three CI platforms.Notes
Independent of #590 (the other 10.4 cherry-pick) — zero file overlap, so the two can merge in either order.
Follow-ups
version.jsonto10.4.0-rc.5before tagging, once this and Cherry-pick the Fallout.Common.ProjectModel migration path onto 10.4 #590 are both in.Fallout.GlobalTools 10.4.0-rc.4on nuget.org withFallout.GlobalToolas the alternate package..config/dotnet-tools.jsonstill pinsfallout.cli 10.3.45; flipping it needs a publishedFallout.GlobalToolnewer than 10.3.49.