Draft
Conversation
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…ort' into alzollin/dotnetSupport
Refactored the code to collect all <dependency> nodes from the .nuspec XML, removing the previous logic that distinguished between ungrouped and grouped dependencies. This streamlines dependency extraction but may mix dependencies from different target frameworks.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…ort' into alzollin/dotnetSupport
Resolve merge conflict from deleted docs/llm-context.md (removed in main). Add 'run' command to setup skill and 'cert info' to signing skill in generate-llm-docs.ps1 so they appear in auto-generated SKILL.md files. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add run entry to README.md Commands Overview under App Identity & Debugging - Add full command reference for winapp run in winapp.agent.md - Update decision tree to include winapp run as preferred path for identity + launch workflow - Add run/debug usage section to setup skill template - Update recommended workflow to use winapp run instead of create-debug-identity for step 4 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Clearly separate the two commands throughout all documentation: - winapp run: registers a loose layout package (full folder) with Add-AppxPackage, simulating an MSIX install. Preferred for most frameworks during iterative development. - create-debug-identity: registers a sparse package pointing to an existing exe via Add-AppxPackage -ExternalLocation. Use when the exe is separate from app code (Electron) or testing sparse scenarios. Updated files: - winapp.agent.md: decision tree, command refs, rule #5, recipes, glossary - README.md: differentiated one-line descriptions - usage.md: added cross-references between both command sections - setup skill: updated key concepts and workflow - identity skill: clarified sparse-only focus with when-to-use guidance - frameworks skill: .NET quick start now uses winapp run - troubleshoot skill: added winapp run to decision tree and prereqs table - dotnet guide: winapp run as primary, create-debug-identity as alternative Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Clarify that .NET projects can add the Microsoft.Windows.SDK.BuildTools.WinApp NuGet package to enable 'dotnet run' with automatic identity registration. The package invokes 'winapp run' under the hood to create a loose layout package and launch the app. Updated files: - dotnet guide: NuGet package as recommended approach, manual MSBuild target as alternative - frameworks skill: added NuGet package to .NET quick start - winapp.agent.md: added dotnet run guidance to .NET section - sample READMEs (dotnet-app, wpf-app): clarified NuGet package usage - NuGet README: updated to describe winapp run mechanism Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
winapp init already adds Microsoft.Windows.SDK.BuildTools.WinApp to the .csproj alongside the other NuGet packages, so dotnet run works out of the box after init. Updated docs to reflect this: - dotnet guide: restructured step 5 to lead with 'dotnet run' since the NuGet package is already present, manual winapp run as alternative - frameworks skill: noted winapp init adds the package automatically - winapp.agent.md: updated .NET section accordingly Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace the manual ApplyDebugIdentity MSBuild target in dotnet-app and wpf-app samples with a PackageReference to Microsoft.Windows.SDK.BuildTools.WinApp. This enables 'dotnet run' to automatically register a loose layout package and launch with identity. Changes: - dotnet-app.csproj: removed ApplyDebugIdentity target, added WinApp NuGet package reference - wpf-app.csproj: same - samples/nuget.config: added local-winapp feed pointing to artifacts/nuget/ so locally-built NuGet packages are resolved - Updated sample READMEs: prerequisite is now building the CLI locally via build-cli.ps1 Both samples restore and build successfully. The PackageMsix targets for Release builds are preserved unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Description This PR adds an option to winapp run to launch the application with an execution alias for scnearios such as console apps or when acces to stdio is needed. It also adds a new command (winapp manifest add-alias) to simplify adding execution alias to a manifest The nuget is also updated with properties for passing the --with-alias option ## Related Issue <!-- Link to any related issues: Fixes #123, Closes #456, Related to #789 --> ## Type of Change <!-- Keep the applicable line(s), delete the rest --> - ✨ New feature ## Checklist <!-- Delete the ones that do not apply to your changes --> - [x] New tests added for new functionality (if applicable) - [x] Tested locally on Windows - [x] Main [README.md](../README.md) updated (if applicable) - [x] [docs/usage.md](../docs/usage.md) updated (if CLI commands changed) - [x] [Language-specific guides](../docs/guides) updated (if applicable) - [x] [Sample projects updated](../samples) to reflect changes (if applicable) - [x] Agent skill templates updated in `docs/fragments/skills/` (if CLI commands/workflows changed) --------- Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com>
…stall (#384) When "Launch and Attach" is invoked without the required debugger extension installed (e.g. C# for `coreclr`), VS Code surfaces a cryptic internal error rather than a clear indication of what's missing. ## Changes - **`DEBUGGER_EXTENSION_MAP`** — maps debugger type strings to their required VS Code extension: - `coreclr` → `ms-dotnettools.csharp` - `cppvsdbg` → `ms-vscode.cpptools` - **`ensureDebuggerExtensionInstalled()`** — called in `createDebugAdapterDescriptor` *before* spawning `winapp run`, so the user gets an actionable error immediately rather than after the app has already launched. If the extension is absent, shows: > *"The "coreclr" debugger requires the C# (ms-dotnettools.csharp) VS Code extension. Please install it and reload VS Code, then retry."* with an **Install Extension** button that calls `workbench.extensions.installExtension` and follows up with a reload reminder. ```typescript const DEBUGGER_EXTENSION_MAP: Record<string, { id: string; name: string }> = { 'coreclr': { id: 'ms-dotnettools.csharp', name: 'C# (ms-dotnettools.csharp)' }, 'cppvsdbg': { id: 'ms-vscode.cpptools', name: 'C/C++ (ms-vscode.cpptools)' }, }; // In createDebugAdapterDescriptor, before winapp run is spawned: if (!await ensureDebuggerExtensionInstalled(debuggerType)) { return new vscode.DebugAdapterInlineImplementation(new NoOpDebugAdapter()); } ``` Unknown debugger types (e.g. `node`) pass through unchanged. > [!WARNING] > > <details> > <summary>Firewall rules blocked me from connecting to one or more addresses (expand for details)</summary> > > #### I tried to connect to the following addresses, but was blocked by firewall rules: > > - `https://api.github.com/graphql` > - Triggering command: `/usr/bin/gh gh pr create --title Fix: Show clear error and offer install prompt when required debugger extension is missing --body ## Summary Fixes the issue where attempting **Launch and Debug** without the C# VS Code extension installed results in a cryptic error about a missing `coreclr` extension. ## Changes Added a `DEBUGGER_EXTENSION_MAP` that maps debugger type strings to t t` (http block) > - Triggering command: `/usr/bin/gh gh pr list --state open /electron/Assets--detach` (http block) > - Triggering command: `/usr/bin/gh gh pr edit 384 --base alzollin/vsc` (http block) > - `https://api.github.com/repos/microsoft/winappCli/pulls/384` > - Triggering command: `/usr/bin/curl curl -s -X PATCH -H Authorization: token -H Accept: application/vnd.github.v3+json REDACTED -d {"base":"alzollin/vsc"} git rkin�� 42298f9b:samples/electron/Assets/AppList.targetsize-36.png` (http block) > > If you need me to access, download, or install something from one of these locations, you can either: > > - Configure [Actions setup steps](https://gh.io/copilot/actions-setup-steps) to set up my environment, which run before the firewall is enabled > - Add the appropriate URLs or hosts to the custom allowlist in this repository's [Copilot coding agent settings](https://github.com/microsoft/winappCli/settings/copilot/coding_agent) (admins only) > > </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Alexandre Zollinger Chohfi <alzollin@microsoft.com> Co-authored-by: Nikola Metulev <nmetulev@users.noreply.github.com> Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Chiara Mooney <34109996+chiaramooney@users.noreply.github.com> Co-authored-by: Zach Teutsch <88554871+zateutsch@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
… with spaces (#386) WinApp CLI commands routed through the VS Code extension fail in PowerShell terminals due to missing `&` call operator, and the debug adapter's `spawn` call breaks when the extension path contains spaces. ## Changes - **Terminal commands — PowerShell `&` operator** (`runWinappCommand`): PowerShell treats a bare quoted string as an expression, not an invocation. Prefix with `&` so it executes: ``` // Before "C:\path\to\winapp.exe" get-winapp-path --global // ParserError in PowerShell // After & "C:\path\to\winapp.exe" get-winapp-path --global // works in PowerShell and cmd.exe ``` - **Debug adapter — replace shell string with args array** (`WinAppDebugAdapterFactory`): The adapter was joining all args into a single string and spawning with `shell: true`, which silently breaks when `winapp.exe` lives under a path with spaces (e.g. `C:\Users\John Smith\...`). Switch to `spawn(cliPath, spawnArgs, { shell: false })` so the OS receives the executable path and arguments directly, with no shell parsing involved: ```typescript // Before const command = [cliPath, 'run', `"${inputFolder}"`, '--manifest', `"${manifest}"`, '--json'].join(' '); spawn(command, { shell: true }); // After const spawnArgs = ['run', inputFolder, '--manifest', manifest, '--json']; spawn(cliPath, spawnArgs, { shell: false }); ``` > [!WARNING] > > <details> > <summary>Firewall rules blocked me from connecting to one or more addresses (expand for details)</summary> > > #### I tried to connect to the following addresses, but was blocked by firewall rules: > > - `https://api.github.com/repos/microsoft/winappCli/pulls/386` > - Triggering command: `/usr/bin/curl curl -s -X PATCH -H Accept: application/vnd.github.v3+json -H Authorization: ****** REDACTED -d {"base": "alzollin/vsc"} sh -c s/REDACTED/win32_window.cpp` (http block) > > If you need me to access, download, or install something from one of these locations, you can either: > > - Configure [Actions setup steps](https://gh.io/copilot/actions-setup-steps) to set up my environment, which run before the firewall is enabled > - Add the appropriate URLs or hosts to the custom allowlist in this repository's [Copilot coding agent settings](https://github.com/microsoft/winappCli/settings/copilot/coding_agent) (admins only) > > </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Alexandre Zollinger Chohfi <alzollin@microsoft.com> Co-authored-by: Nikola Metulev <nmetulev@users.noreply.github.com> Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Chiara Mooney <34109996+chiaramooney@users.noreply.github.com> Co-authored-by: Zach Teutsch <88554871+zateutsch@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
…zollin/vsc # Conflicts: # .github/plugin/agents/winapp.agent.md # .github/plugin/skills/winapp-cli/frameworks/SKILL.md # .github/plugin/skills/winapp-cli/manifest/SKILL.md # .github/plugin/skills/winapp-cli/setup/SKILL.md # .github/plugin/skills/winapp-cli/troubleshoot/SKILL.md # README.md # docs/cli-schema.json # docs/dotnet-run-support.md # docs/fragments/skills/winapp-cli/frameworks.md # docs/fragments/skills/winapp-cli/setup.md # docs/fragments/skills/winapp-cli/troubleshoot.md # docs/guides/dotnet.md # docs/guides/rust.md # docs/usage.md # samples/dotnet-app/dotnet-app.csproj # samples/wpf-app/wpf-app.csproj # scripts/build-cli.ps1 # scripts/package-nuget.ps1 # scripts/setup-winapprun.ps1 # src/winapp-CLI/Directory.Packages.props # src/winapp-CLI/WinApp.Cli.Tests/FakeAppLauncherService.cs # src/winapp-CLI/WinApp.Cli.Tests/MsixServiceTests.cs # src/winapp-CLI/WinApp.Cli.Tests/RunCommandTests.cs # src/winapp-CLI/WinApp.Cli/Commands/RunCommand.cs # src/winapp-CLI/WinApp.Cli/Commands/WinAppRootCommand.cs # src/winapp-CLI/WinApp.Cli/Helpers/HostBuilderExtensions.cs # src/winapp-CLI/WinApp.Cli/NativeMethods.txt # src/winapp-CLI/WinApp.Cli/Services/AppLauncherService.cs # src/winapp-CLI/WinApp.Cli/Services/IAppLauncherService.cs # src/winapp-CLI/WinApp.Cli/Services/ManifestService.cs # src/winapp-CLI/WinApp.Cli/Services/MsixService.cs # src/winapp-NuGet/README.md # src/winapp-NuGet/build/Microsoft.Windows.SDK.BuildTools.WinApp.props # src/winapp-NuGet/build/Microsoft.Windows.SDK.BuildTools.WinApp.targets
#410) ## Description **Problem** The VS Code extension's "Launch and Debug" failed when appxmanifest.xml was at the workspace root because: 1. The glob pattern **/*/AppxManifest.xml required at least one directory depth, missing root-level manifests entirely. 2. The extension derived the build output folder (inputFolder) from the manifest location, which is incorrect when the manifest isn't inside the build output directory. **Solution** Redesigned the launch config to be input-folder-first, aligning with the CLI's winapp run <input-folder> command: - Removed the glob-based manifest search (buildOutputManifest). Instead, the extension now takes inputFolder as the primary config — the path to the build output directory containing the app binaries. - Auto-discovers build output folders when inputFolder isn't set in launch.json: scans the workspace for folders containing .exe files and presents them as a quick pick. If only one is found, it's used automatically. - Added optional manifest config property for explicit manifest path. When omitted, the CLI auto-detects from the input folder or CWD. - Filters out non-build directories from the exe search: node_modules, .git, AppX, .winapp, obj, .vs, packages. New launch.json config ``` { "type": "winapp", "request": "launch", "name": "WinApp: Launch and Attach", "debuggerType": "coreclr", "inputFolder": "${workspaceFolder}\\bin\\Debug\\net10.0-windows10.0.26100.0\\win-arm64" } ``` inputFolder and manifest are both optional — if inputFolder is omitted, the extension discovers build folders automatically. If manifest is omitted, the CLI handles auto-detection. ## Usage Example <!-- If this PR adds or changes commands, flags, or APIs, include a short code snippet --> <!-- Example: ```bash winapp store app list ``` --> ## Related Issue Fix #370 ## Type of Change - ♻️ Refactoring ## Checklist - [x] Tested locally on Windows ## Screenshots / Demo https://github.com/user-attachments/assets/d9b4c7d1-d74b-45de-9c37-638ad2044316 ## Additional Notes <!-- Any additional information that reviewers should know --> ## AI Description <!-- ai-description-start --> _This section is auto-generated by AI when the PR is opened or updated. To opt out, delete this entire section including the marker comments._ <!-- ai-description-end --> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Description Add README for VS Code extension. Will be displayed in details section of the extension. ## Usage Example ## Related Issue <!-- Link to any related issues: Fixes #123, Closes #456, Related to #789 --> ## Type of Change <!-- Keep the applicable line(s), delete the rest --> - 📝 Documentation ## Checklist <!-- Delete the ones that do not apply to your changes --> ## Screenshots / Demo ## Additional Notes <!-- Any additional information that reviewers should know --> ## AI Description <!-- ai-description-start --> _This section is auto-generated by AI when the PR is opened or updated. To opt out, delete this entire section including the marker comments._ <!-- ai-description-end -->
…into alzollin/vsc
Build Metrics ReportBinary Sizes
Test Results✅ 718 passed out of 718 tests in 396.1s (+50.0s vs. baseline) Test Coverage❌ 20.6% line coverage, 35.8% branch coverage · ✅ no change vs. baseline CLI Startup Time45ms median (x64, Updated 2026-04-10 00:52:29 UTC · commit |
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
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.
Description
Merge VS Code extension into main. Includes Winapp commands, launch and debug, and README. Does not include extension in publish.
Adds WinUI templates.
Usage Example
Install extension in VS Code and use commands/launch windows apps.
Related Issue
Type of Change
Checklist
Screenshots / Demo
Additional Notes
AI Description
This PR merges the VS Code extension into the main project, including new Winapp commands, launch and debugging support, and enhancements to the README. It adds WinUI templates to facilitate Windows app development, allowing developers to utilize these templates within their projects.
Usage example for adding an execution alias: