fix(build): make build/clean tools non-blocking to match async contract - #96
Merged
CalvinAllen merged 1 commit intoJul 8, 2026
Conversation
BuildSolution, BuildProject and CleanSolution called the EnvDTE SolutionBuild APIs with WaitForBuildToFinish/WaitForCleanToFinish set to true, on the UI thread.
This blocks the Visual Studio main thread until the entire build/clean completes, which contradicts the tool description ("runs asynchronously; use build_status to check progress; returns immediately after starting the build").
Two consequences:
- For large solutions the RPC call never returns in time and the MCP client reports "The operation timed out.",
instead of "Build started".
- While the UI thread is blocked, build_status/build_cancel cannot run,
so the documented polling workflow is impossible.
Pass false so the build/clean is queued and the call returns immediately,
letting build_status observe the InProgress -> Done transition as intended.
This was referenced Sep 3, 2026
CalvinAllen
added a commit
that referenced
this pull request
Sep 3, 2026
Adds seven MCP tools over Test Explorer: test_run_all, test_debug_all, test_run, test_debug, test_cancel, test_status and test_stats. The extension cannot reference Microsoft.VisualStudio.TestWindow.Interfaces.dll at compile time. It is absent from the Microsoft.VisualStudio.SDK metapackage, nuget.org carries nothing newer than 11.0.61030 (2012), and $(DevEnvDir) is undefined under dotnet build, which is how this repo builds locally and in CI. TestExplorerInterop therefore resolves ITestExplorerStatsService and IOperationState by MEF contract name and reads them reflectively. The surface needed is one bool, one struct of four ints and one event, and it is identical in VS 2022 17.14 and VS 2026 18.0. Run tools start the run and return immediately, matching the non-blocking contract the build tools were corrected to in #96. Completion is observed by subscribing to IOperationState rather than by blocking, so the UI thread is never held; test_status reports the collapsed run state and current counts. test_stats distinguishes "Test Explorer not initialized" from "no tests", so an uninitialized window cannot be misread as a solution with zero tests. The *InContext commands act on the caret, so test_run and test_debug resolve the requested class or method through the workspace symbol search, open the file and position the caret before issuing the command. Test Explorer exposes no documented cancel command, so test_cancel probes candidate names and uses the first the running Visual Studio recognises. Commands are probed with Command.IsAvailable before execution, because ExecuteCommand throws when a command is disabled, which for Test Explorer is the normal state before discovery finishes.
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
2 participants
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.
Problem
build_solution,build_project, andclean_solutionare documented as asynchronous ("runs asynchronously; usebuild_statusto check progress; returns immediately after starting the build"), but they block until the build/clean fully completes.This shows up in daily real-world use: I drive builds through this MCP on a large Unreal Engine 5 (C++) solution, and
build_solutionconsistently returnsThe operation timed out.instead ofBuild started. Because the blocking call also freezes the Visual Studio UI thread for the whole build,build_statusandbuild_cancelcan't run either — so the documented "start build, then pollbuild_status" workflow is impossible on any large solution.Root cause
src/CodingWithCalvin.MCPServer/Services/VisualStudioService.cscalls the EnvDTESolutionBuildAPIs with the wait flag set totrue, right afterSwitchToMainThreadAsync():The final boolean is
WaitForBuildToFinish/WaitForCleanToFinish;trueblocks on the UI thread until the whole operation finishes.Fix
Pass
falseso the build/clean is queued and the call returns immediately. This restores the documented async behavior and letsbuild_statusobserve theInProgress -> Donetransition as intended.Testing
No automated coverage — the repo has no test harness yet (#11); this is a minimal per-call flag flip.