You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The sources live under `vendor/vs-solutionpersistence/` as a git submodule tracking our personal-account repo. Our wrapper csproj at `src/Fallout.VisualStudio.SolutionPersistence/` multi-targets netstandard2.0;net8.0;net10.0, compiles the submodule's .cs files (92 source files), and packs as Fallout.VisualStudio.SolutionPersistence with AssemblyName=Microsoft.VisualStudio.SolutionPersistence to preserve type identity for Fallout.SolutionModel consumers.
This is brittle:
A git submodule pointing at a personal-account repo couples the project's build to one maintainer's GitHub account staying alive and accessible.
Rebasing the submodule on upstream requires manual coordination across three forks every time Microsoft ships a change we want.
The netstandard2.0 patch is the load-bearing reason we forked, but upstream's targeting policy may have shifted — worth re-checking.
Submodules add real cognitive load for new contributors (git submodule update --init --recursive, etc.).
Chris explicitly does not want another side repository to replace this one. Two acceptable paths only:
Acceptable paths
A) Switch back to the upstream nuget package
If Microsoft.VisualStudio.SolutionPersistence on nuget.org now supports the TFMs we need (or we can drop one of our TFMs to match what's supported), simply reference the upstream package and delete Fallout.VisualStudio.SolutionPersistence + the submodule entirely.
Investigation needed: what TFMs does the current upstream package support?
What's our actual minimum TFM requirement? The submodule csproj targets netstandard2.0;net8.0;net10.0 — is netstandard2.0 still load-bearing (probably yes for the source generator path) or can we drop it?
Has upstream changed their stance on netstandard2.0 since matkoch's fork was created?
B) Inline the source files directly into Fallout
If upstream doesn't fit, copy the necessary source files directly into src/Fallout.VisualStudio.SolutionPersistence/ (no submodule, no separate repo). Track upstream by manual sync when needed — git diff against a clean clone of upstream Microsoft, apply patches.
Smaller surface than the current 92-file submodule? Identify which files we actually need.
License + attribution preserved via per-file headers and a NOTICE file referencing Microsoft + matkoch.
Sync cadence is whenever a Microsoft fix matters; otherwise leave it alone.
NOT acceptable
Replacing the personal-account submodule with another personal- or org-account side repo (e.g. Fallout-build/vs-solutionpersistence). The whole point is to stop maintaining a separate repo.
Action
Audit current upstream Microsoft.VisualStudio.SolutionPersistence nuget package — TFMs supported, version, breaking changes since the fork point
Decide path A vs B based on the audit (one PR for each path's spike, or a write-up issue, whichever's faster)
If A: replace Fallout.VisualStudio.SolutionPersistence csproj with a PackageReference in Directory.Packages.props; update Fallout.SolutionModel's reference; delete vendor/vs-solutionpersistence/ and the submodule entry in .gitmodules; archive ChrisonSimtian/vs-solutionpersistence on GitHub
If B: copy the load-bearing .cs files into src/Fallout.VisualStudio.SolutionPersistence/; preserve license headers + add NOTICE; delete vendor/vs-solutionpersistence/ and the submodule entry; document the manual-sync recipe in docs/agents/conventions.md or a sibling doc; archive ChrisonSimtian/vs-solutionpersistence
Either way: ensure Fallout.SolutionModel still builds + tests pass on all three current TFMs
Coordinate with
chore(ci): drop Qodana #11 / Fallout-build org transfer — once the GitHub org exists, archive-vs-keep on ChrisonSimtian/vs-solutionpersistence is part of the personal-asset cleanup
The Fallout.SolutionModel consumer — it's the only direct dependent
AGENTS.md → docs/agents/repository-layout.md (vendored entry) — update once this lands
Done when
No vendor/ directory, no .gitmodules entry, no submodule for solution-persistence
No side repository under any account being relied on for this dependency
Either upstream nuget consumed directly, or sources inlined under src/Fallout.VisualStudio.SolutionPersistence/ with proper license/attribution
ChrisonSimtian/vs-solutionpersistence archived on GitHub (or transferred if path A and the fork is no longer needed by anyone)
Why
`Fallout.VisualStudio.SolutionPersistence` is currently a fork of a fork of Microsoft's solution-persistence library:
netstandard2.0)netstandard2.0patches with attribution)The sources live under `vendor/vs-solutionpersistence/` as a git submodule tracking our personal-account repo. Our wrapper csproj at `src/Fallout.VisualStudio.SolutionPersistence/` multi-targets
netstandard2.0;net8.0;net10.0, compiles the submodule's.csfiles (92 source files), and packs asFallout.VisualStudio.SolutionPersistencewithAssemblyName=Microsoft.VisualStudio.SolutionPersistenceto preserve type identity forFallout.SolutionModelconsumers.This is brittle:
netstandard2.0patch is the load-bearing reason we forked, but upstream's targeting policy may have shifted — worth re-checking.git submodule update --init --recursive, etc.).Chris explicitly does not want another side repository to replace this one. Two acceptable paths only:
Acceptable paths
A) Switch back to the upstream nuget package
If
Microsoft.VisualStudio.SolutionPersistenceon nuget.org now supports the TFMs we need (or we can drop one of our TFMs to match what's supported), simply reference the upstream package and deleteFallout.VisualStudio.SolutionPersistence+ the submodule entirely.netstandard2.0;net8.0;net10.0— isnetstandard2.0still load-bearing (probably yes for the source generator path) or can we drop it?netstandard2.0since matkoch's fork was created?B) Inline the source files directly into Fallout
If upstream doesn't fit, copy the necessary source files directly into
src/Fallout.VisualStudio.SolutionPersistence/(no submodule, no separate repo). Track upstream by manual sync when needed —git diffagainst a clean clone of upstream Microsoft, apply patches.NOTICEfile referencing Microsoft + matkoch.NOT acceptable
Fallout-build/vs-solutionpersistence). The whole point is to stop maintaining a separate repo.Action
Microsoft.VisualStudio.SolutionPersistencenuget package — TFMs supported, version, breaking changes since the fork pointFallout.VisualStudio.SolutionPersistencecsproj with aPackageReferenceinDirectory.Packages.props; updateFallout.SolutionModel's reference; deletevendor/vs-solutionpersistence/and the submodule entry in.gitmodules; archiveChrisonSimtian/vs-solutionpersistenceon GitHub.csfiles intosrc/Fallout.VisualStudio.SolutionPersistence/; preserve license headers + addNOTICE; deletevendor/vs-solutionpersistence/and the submodule entry; document the manual-sync recipe indocs/agents/conventions.mdor a sibling doc; archiveChrisonSimtian/vs-solutionpersistenceFallout.SolutionModelstill builds + tests pass on all three current TFMsCoordinate with
ChrisonSimtian/vs-solutionpersistenceis part of the personal-asset cleanupFallout.SolutionModelconsumer — it's the only direct dependentdocs/agents/repository-layout.md(vendored entry) — update once this landsDone when
vendor/directory, no.gitmodulesentry, no submodule for solution-persistencesrc/Fallout.VisualStudio.SolutionPersistence/with proper license/attributionChrisonSimtian/vs-solutionpersistencearchived on GitHub (or transferred if path A and the fork is no longer needed by anyone)