Problem
When launching via the WinApp debugger (F5), vscode.debug.startDebugging(...) returns a falsy result even though the coreclr session actually starts and the app comes up successfully. Anyone scripting or trusting F5's return value is misled into thinking the launch failed when it succeeded.
Proposed solution
- Return a truthful value from the debug launch path — resolve success once the
coreclr session has actually started (e.g. via the debug session start event) rather than returning early with false.
- If the current return semantics are intentional, document them so callers know
false doesn't mean failure.
Additional context
Observed with microsoft-winappcli.winapp v0.2.1-prerelease.6, VS Code 1.127.0, Windows on ARM. Across four apps, F5 launched and attached cleanly each time while startDebugging returned false; success had to be inferred from the start:coreclr session event and the app process appearing. The debugger flow itself is excellent once configured — this is purely about the misleading return value.
Problem
When launching via the WinApp debugger (F5),
vscode.debug.startDebugging(...)returns a falsy result even though thecoreclrsession actually starts and the app comes up successfully. Anyone scripting or trusting F5's return value is misled into thinking the launch failed when it succeeded.Proposed solution
coreclrsession has actually started (e.g. via the debug sessionstartevent) rather than returning early withfalse.falsedoesn't mean failure.Additional context
Observed with
microsoft-winappcli.winappv0.2.1-prerelease.6, VS Code 1.127.0, Windows on ARM. Across four apps, F5 launched and attached cleanly each time whilestartDebuggingreturnedfalse; success had to be inferred from thestart:coreclrsession event and the app process appearing. The debugger flow itself is excellent once configured — this is purely about the misleading return value.