Keep the workspace in sync with the disk; add UnloadSolution; move to .NET 10 / MCP SDK 2.2.0 - #25
Open
Jaben wants to merge 2 commits into
Open
Keep the workspace in sync with the disk; add UnloadSolution; move to .NET 10 / MCP SDK 2.2.0#25Jaben wants to merge 2 commits into
Jaben wants to merge 2 commits into
Conversation
MSBuildWorkspace never watches the file system, so a document edited outside SharpTools (editor, git, another tool) was invisible and the next write rewrote it from the stale buffer. Every tool now syncs first: documents are stat'ed and only the ones that changed are re-read; files added or removed, or a changed project file, trigger a reload. Results carry an <externalChanges> note naming what was re-read. Writes are diffed against the solution the tool actually started from and rebased onto the workspace, so untouched files are never rewritten and an edit to a document that changed underneath fails with a retry message instead of losing the other change. Adds SharpTool_UnloadSolution and an xunit project covering the sync and conflict paths. Supersedes the FileSystemWatcher/full-reload approach proposed in kooshi#11.
…other packages All projects now target net10.0. ModelContextProtocol 0.4.0-preview.3 -> 2.2.0 needed no code changes apart from pinning the SharpTask prompt name, since 2.x defaults unnamed prompts to snake_case. Roslyn packages aligned at 5.9.0 (Workspaces.MSBuild had been left at 5.6.0, tripping NU1608). Microsoft.Build.Locator 1.11.2's copy-local check is disabled in Directory.Build.props: the flagged assemblies are Microsoft.Build.Framework (transitive from Roslyn) and NuGet.Frameworks (needed in-process by NuGet.Protocol), and MSBuild itself only runs in Roslyn's out-of-proc BuildHost, so the version-mixing hazard the check guards against does not apply. Also bumps ICSharpCode.Decompiler, LibGit2Sharp, NuGet.Protocol, Serilog, System.CommandLine, test SDK/xunit runner, and drops the in-box System.Reflection.Metadata reference.
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.
MSBuildWorkspace never watches the file system, so a document edited outside SharpTools (an editor, git, another agent tool) was invisible, and the next SharpTools write rewrote that file from the stale in-memory buffer — I hit this in daily use and confirmed it silently reverted outside edits. This is the per-document take on what #11 set out to do: instead of a FileSystemWatcher and full reloads, every tool call first stats the loaded documents and re-reads only the ones whose content changed (~10 ms for a 420-document solution); files added or removed under a project directory, or a changed project/solution file, trigger a reload. Tool results end with an
<externalChanges>note naming what was re-read (or that the solution reloaded) so the agent knows its picture of those files is old. Writes are diffed against the solution the tool actually started from (tracked per invocation) and rebased onto the workspace's own solution, so untouched files are never rewritten, and an edit to a document that changed underneath fails with a retry message instead of losing the other change. Also addsSharpTool_UnloadSolutionand an xunit project (SharpTools.Tools.Tests) covering visibility, no-clobber, untouched-not-rewritten, add/remove/project-file reload, sequential same-file edits, and the stale/drift rejections; beyond the unit tests this was exercised end-to-end through the stdio server against a real 420-file net10 solution.The second commit moves everything to net10.0 and updates packages: ModelContextProtocol 0.4.0-preview.3 → 2.2.0 (no code changes except pinning the
SharpTaskprompt name, since 2.x defaults unnamed prompts to snake_case), Roslyn 5.9.0 across the board, Microsoft.Build.Locator 1.11.2 (its new copy-local check is disabled inDirectory.Build.props— the flagged assemblies are Microsoft.Build.Framework, transitive from Roslyn, and NuGet.Frameworks, which NuGet.Protocol needs in-process, and MSBuild itself only runs in Roslyn's out-of-proc BuildHost), plus Decompiler, LibGit2Sharp, NuGet.Protocol, Serilog, System.CommandLine and the test SDK. Happy to split that into its own PR if you'd rather review them separately.