Skip to content

fix(packaging): publish Fallout.VisualStudio.SolutionPersistence; bump to 10.3 - #107

Merged
ChrisonSimtian merged 2 commits into
mainfrom
fix/solutionpersistence-publish
May 22, 2026
Merged

fix(packaging): publish Fallout.VisualStudio.SolutionPersistence; bump to 10.3#107
ChrisonSimtian merged 2 commits into
mainfrom
fix/solutionpersistence-publish

Conversation

@ChrisonSimtian

Copy link
Copy Markdown
Collaborator

Summary

  • Fallout.SolutionModel 10.2.24–10.2.34 are unrestorable: the vendored SolutionPersistence wrapper was IsPackable=false, so dotnet pack emitted a dep on the assembly name (Microsoft.VisualStudio.SolutionPersistence) at the Fallout version. That ID exists on nuget.org (real Microsoft package, max 1.0.52) but at 10.2.x it doesn't — restore fails for downstream consumers.
  • Wrapper now packs as Fallout.VisualStudio.SolutionPersistence (PackageId set explicitly; AssemblyName stays Microsoft.VisualStudio.SolutionPersistence for drop-in type identity). Initial ID was reserved on nuget.org manually (0.0.1-reserve) per the prefix gotcha.
  • Bumps version.json from 10.2 → 10.3 so the fix lands on a fresh minor line, clearly delineating it from the broken 10.2.24–34 range.

Affected published versions (to unlist after merge)

Package Bad versions
Fallout.SolutionModel 10.2.24, 10.2.25, 10.2.26, 10.2.28, 10.2.31, 10.2.32, 10.2.34
Fallout.Common (same 7)
Fallout.Build (same 7)
Fallout.ProjectModel (same 7)
Fallout.Components (same 7)

Fallout.SourceGenerators is unaffected (ProjectReference uses PrivateAssets="all"; DLL is bundled into the analyzer payload).

Test plan

  • dotnet pack src/Fallout.VisualStudio.SolutionPersistence produces a clean nupkg with correct ID and polyfill deps on netstandard2.0
  • dotnet pack src/Fallout.SolutionModel now declares <dependency id="Fallout.VisualStudio.SolutionPersistence" .../>
  • CI's release workflow publishes both this package and the rest of Fallout.* to nuget.org at 10.3.0+
  • Manually unlist 35 affected versions on nuget.org once 10.3.0 is published

🤖 Generated with Claude Code

ChrisonSimtian and others added 2 commits May 22, 2026 19:45
…p to 10.3

Fallout.SolutionModel 10.2.24 through 10.2.34 are unrestorable: the
wrapper csproj for the vendored SolutionPersistence fork was marked
IsPackable=false, so dotnet pack fell back to emitting a dependency on
the assembly name (Microsoft.VisualStudio.SolutionPersistence) at the
Fallout version (10.2.x). That ID exists on nuget.org (real Microsoft
package, max 1.0.52) but the 10.2.x versions don't, so restore fails
for any consumer of Fallout.SolutionModel, Fallout.Common,
Fallout.Build, Fallout.ProjectModel, or Fallout.Components.

Fix:
- Make src/Fallout.VisualStudio.SolutionPersistence/ packable as
  Fallout.VisualStudio.SolutionPersistence (PackageId set explicitly;
  AssemblyName stays Microsoft.VisualStudio.SolutionPersistence for
  drop-in type identity). Initial ID reservation (0.0.1-reserve) was
  uploaded manually to nuget.org to claim the ID under the Fallout.*
  prefix — see [[project_nuget_prefix_gotcha]]. CI's PushPackageFiles
  filter only excludes Nuke.*, so the wrapper now flows through.
- Bump version.json from 10.2 → 10.3 so the fixed line is clearly
  delineated from the broken 10.2.24–34 range (which will be unlisted
  on nuget.org as a follow-up).
- Update docs/dependencies.md vendored-source row to note the package
  now ships to nuget.org alongside the rest of Fallout.*.

Fallout.SourceGenerators is unaffected: its ProjectReference to the
wrapper uses PrivateAssets="all" and it bundles the DLL into the
analyzer payload, so no public Microsoft.* dep ever leaked.

Verification: dotnet pack on the wrapper produces a clean nupkg;
Fallout.SolutionModel.nuspec now declares
`<dependency id="Fallout.VisualStudio.SolutionPersistence" ... />`
instead of the bogus Microsoft.* reference.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ChrisonSimtian
ChrisonSimtian merged commit 692d3aa into main May 22, 2026
1 check passed
@ChrisonSimtian
ChrisonSimtian deleted the fix/solutionpersistence-publish branch May 22, 2026 08:07
ChrisonSimtian added a commit that referenced this pull request May 22, 2026
Without --skip-duplicate, a single failed push aborts the whole publish
target, and a rerun then fails with HTTP 409 ("already exists") on
every package that did succeed the first time. That makes release.yml
non-recoverable from any partial-failure state, which we hit twice
today (#107 → SolutionPersistence prefix-reservation, then again
mid-key-permission-debug).

With --skip-duplicate, the push step returns success when a version
is already on nuget.org. Reruns are now safe and only the genuinely
missing packages get uploaded.

Wired via IPublish.PushSettings override (Configure<DotNetNuGetPushSettings>),
which composes on top of the existing PushSettingsBase in
Fallout.Components.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant