Fix VS Code extension Launch and Debug failing when AppxManifest.xml is at workspace root#385
Fix VS Code extension Launch and Debug failing when AppxManifest.xml is at workspace root#385Copilot wants to merge 10 commits intoalzollin/vscfrom
Conversation
Co-authored-by: chiaramooney <34109996+chiaramooney@users.noreply.github.com>
Build Metrics ReportBinary Sizes
Test Results✅ 647 passed out of 647 tests in 390.6s (+65.3s vs. baseline) Test Coverage❌ 30.8% line coverage, 42.4% branch coverage · ✅ no change vs. baseline CLI Startup Time43ms median (x64, Updated 2026-04-06 18:12:25 UTC · commit |
|
@copilot Your base branch should have been alzollin/vsc but it looks like you began with a checkout from main. Please adjust this PR to use alzollin/vsc as the base branch. You may need to revert all of your changes so your branch exactly matches alzollin/vsc and then reapply your fixes. |
The PR base is already set to The actual code changes are only in 2 files ( Unfortunately I'm unable to force-push to clean up the branch history (the tooling I have available performs a rebase before push, which fails due to conflicts between the main-merged history and alzollin/vsc). If you'd like, I can close this PR and open a fresh one from a clean branch based directly on |
|
@copilot please close and open and fresh PR with alzollin/vsc as the base. the diff should be only your changes. |
|
@chiaramooney I've opened a new pull request, #404, to work on those changes. Once the pull request is ready, I'll request review from you. |
|
@copilot That pull requests looked like you were trying to merge changes into the copilot/fix-vscode-extension-launch-debug branch and not the alzollin/vsc branch. The PR should be against alzollin/vsc and include just the changes to the vscode extension needed to fix the bug. |
Co-authored-by: chiaramooney <34109996+chiaramooney@users.noreply.github.com>
Agent-Logs-Url: https://github.com/microsoft/winappCli/sessions/18ffd656-2811-410c-bac4-b81ff4ead9eb Co-authored-by: chiaramooney <34109996+chiaramooney@users.noreply.github.com>
Co-authored-by: chiaramooney <34109996+chiaramooney@users.noreply.github.com>
Done — the branch has been cleaned up. The PR now differs from
The branch is now clean — |
## Problem `winapp run` called `RemovePackageAsync` without `RemovalOptions`, which wiped the package's `LocalState`, `RoamingState`, and `Settings` folders on every re-deploy. Apps writing to `ApplicationData.Current.LocalFolder` or `LocalApplicationData` would lose all persisted data between runs. This was reported ~15 times as a pain point — developers waste 10-30 minutes debugging why data doesn't persist across restarts. ## Fix - `UnregisterAsync` now passes `RemovalOptions.PreserveApplicationData` by default when removing dev-mode packages before re-registration. This is a Windows API flag specifically designed for packages registered in development mode. - Added `--clean` flag to `winapp run` for when a fresh start is needed (e.g., reset corrupted state or test first-run behavior). - Explicit unregister (`winapp unregister`, `--unregister-on-exit`) still removes application data, since those are intentional cleanup actions. ## Changes | Area | Files | |------|-------| | Core fix | `PackageRegistrationService.cs`, `IPackageRegistrationService.cs` | | Plumbing | `MsixService.Identity.cs`, `IMsixService.cs`, `RunCommand.cs`, `UnregisterCommand.cs` | | npm SDK | `winapp-commands.ts` | | Tests | `FakeMsixService.cs`, `FakePackageRegistrationService.cs` | | Docs | `usage.md` + autogenerated `cli-schema.json`, `npm-usage.md`, `SKILL.md` | ## Behavior matrix | Scenario | App data | |----------|----------| | `winapp run ./bin/Debug` (re-deploy) | **Preserved** ✅ (new default) | | `winapp run ./bin/Debug --clean` | Wiped | | `winapp unregister` | Wiped | | `winapp run --unregister-on-exit` | Wiped on exit | --------- Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Remove 12 method definitions that are duplicated in MsixService.Identity.cs, fixing CS0111 'already defines a member' build errors: - AddSparseIdentityAsync - AddLooseLayoutIdentityAsync - EnsureWindowsAppRuntimeInstalledAsync - EmbedMsixIdentityToExeAsync - EmbedManifestFileToExeAsync - TryExtractManifestFromExeAsync - RunMtToolAsync - GenerateSparsePackageStructureAsync - CreateDebugIdentity - UnregisterExistingPackageAsync - RegisterSparsePackageAsync - RegisterLooseLayoutPackageAsync These methods are now defined only in MsixService.Identity.cs (the authoritative partial class file). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The extension's Launch and Debug failed for projects with
AppxManifest.xmlat the workspace root due to a glob pattern requiring at least one directory level (**/*/), and incorrectly assumed the manifest always lives inside the build output directory.Changes
src/winapp-VSC/src/extension.ts**/*/AppxManifest.xml→**/AppxManifest.xml— now matches manifests at any depth including root.winappalongsideAppXto prevent winapp-generated debug manifests from being picked upinputFolderdefault: Changed frompath.dirname(manifest)tofolder.uri.fsPath(workspace root) — correct when--manifestis always passed explicitlyconfig.manifestoption: When set, skips glob entirely and uses the path directly; recommended for root-manifest projectsmanifestoptionsrc/winapp-VSC/package.jsonmanifestschema property: explicit manifest path, bypasses globinputFolderschema property (was code-only before): directswinapp runto the correct binary directory when it differs from the manifest locationbuildOutputManifestdefault and description to reflect the fixed patterninitialConfigurations(removed hardcoded old pattern){ "type": "winapp", "request": "launch", "name": "WinApp: Launch and Attach", "debuggerType": "coreclr", "manifest": "${workspaceFolder}/AppxManifest.xml", "inputFolder": "${workspaceFolder}/bin/Debug" }