Make F5 auto-install the required debugger extension on first run (#32)#55
Draft
chiaramooney wants to merge 8 commits into
Draft
Make F5 auto-install the required debugger extension on first run (#32)#55chiaramooney wants to merge 8 commits into
chiaramooney wants to merge 8 commits into
Conversation
The coreclr debugger requires ms-dotnettools.csharp, but a brand-new user's first F5 failed with a passive notification and a half-started session. - Detect the missing debugger extension early, in resolveDebugConfiguration, so the session is cancelled cleanly instead of half-starting. - Turn the error into an actionable modal that installs the extension with progress, activates it in-session, and continues automatically (falling back to a reload prompt only if VS Code hasn't surfaced it yet). - Keep the adapter-factory check as a safety net. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
When no debuggerType is configured (e.g. first F5 with no launch.json), the default assumed coreclr and offered the C# extension even for C++ projects. - Add resolveDebuggerType: if a debuggerType is set, ensure its extension; if not, reuse an already-installed debugger extension, otherwise show a modal letting the user pick C# (.NET) or C/C++ to match their project. - Persist the chosen type onto the config so attach uses the matching debugger. - Extract installAndActivateExtension so both the single-extension and choose-extension paths share install/activate/reload-fallback logic. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
…32) Two follow-ups to the choose-your-debugger flow: - When the reused debugger extension (path #2) turns out to be the wrong one for the project, startDebugging resolves false. Detect that, kill the launched process, and show an actionable modal letting the user install the debugger that matches their project, then retry. - When WinApp auto-installs a debugger extension (any path), log the reason to a new 'WinApp Debugger' output channel and notify the user, so it's never a surprise why an extension was added. Extracts promptAndInstallDebuggerChoice so first-run and attach-failure share the same C#/C++ picker. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
Honor debugger recovery choices, add Node/Electron first-run handling, and cover debugger resolver decisions with unit tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
Remove hard-coded coreclr launch defaults, infer debugger type from project files before installed-extension reuse, and detect immediate child attach termination for retry recovery. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
Avoid classifying native projects with package.json as Node and make parent debug cleanup reliable when winapp run exits during the early attach watch. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
Treat CMake and other native markers as ambiguity for Node inference, and wait briefly for winapp run to exit before classifying early child debugger termination as attach failure. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
Remove changes introduced during the review loop that were outside the scope of issue #32 (auto-install the required debugger extension on first F5/WinApp debug): - Remove project-type inference (inferDebuggerTypeFromProject) from debugger-resolver.ts, extension.ts (resolveDebuggerType no longer takes a folder), and its unit tests. When no debuggerType is set, WinApp reuses an installed debugger or prompts the user to pick one. - Revert the debug-adapter factory to the simpler attach flow: launch the app, start the child debug session, and on a false result kill the run process and surface the choose-your-debugger prompt. This drops the async early-termination detection, grace period, and auto-retry loop. - Update README/package.json wording to remove "infers". The orphaned-process teardown hardening is moved to a separate PR. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5ce7415c-8966-43ec-ad27-59a68e7ed74b
chiaramooney
added a commit
that referenced
this pull request
Jul 14, 2026
…55 Scope PR #48 back to the DAP handshake fix. Extract NoOpDebugAdapter into a single src/noop-debug-adapter.ts module (with unit tests) instead of three separate helper files. Remove the missing-extension and child-startDebugging failure-path handling added during review: PR #55 already owns both cases (early detection in resolveDebugConfiguration plus factory safety net), so keeping them here duplicated logic and conflicted with #55. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8e0795e4-7d02-4d00-ad31-be892aaa8fb3
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.
Summary
Fixes #32 — on a clean install, the very first F5 → WinApp debugger failed because
coreclrrequires the C# (ms-dotnettools.csharp) extension, which wasn't installed. The old flow showed a passive notification and dropped the user into a half-started session, telling them to manually reload and retry.Changes
resolveDebugConfiguration, before the session (and the input-folder picker) starts. If the extension is missing and the user declines, the session is cancelled cleanly instead of half-starting.This is debugger-type–aware, so
cppvsdbg(C/C++) andnode(built-in) are handled the same way viaDEBUGGER_EXTENSION_MAP.Alternative considered:
extensionDependenciesThe issue's "best-first" suggestion was to add
ms-dotnettools.csharptoextensionDependencies(zero-click, always installed). I did not take that route because it force-installs the C# extension on every WinApp user — including C++ (cppvsdbg) WinUI developers and users who only use the manifest editor / packaging commands and never debug .NET. The runtime approach fully removes the guaranteed first-run failure for the default coreclr path while staying surgical. Happy to addextensionDependencies/extensionPackon top if the team prefers the zero-click guarantee.Testing
npm run compile-tsc— cleannpm run lint— 0 errors (pre-existing warnings unrelated)npm run package(esbuild production) — build completenpm run test:unit— 592 passing, 0 failing