{"id":1370,"date":"2026-08-14T11:43:25","date_gmt":"2026-08-14T18:43:25","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/ifdef-windows\/?p=1370"},"modified":"2026-08-14T11:43:25","modified_gmt":"2026-08-14T18:43:25","slug":"windows-app-development-cli-v0-6-create-new-winui-applications-sign-packages-with-azure-and-more","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/ifdef-windows\/windows-app-development-cli-v0-6-create-new-winui-applications-sign-packages-with-azure-and-more\/","title":{"rendered":"Windows App Development CLI v0.6 – create new WinUI applications, sign packages with Azure, and more"},"content":{"rendered":"

\"Blog<\/a><\/p>\n

Windows App Development CLI v0.6.0 has just shipped and contains a ton of new features. Much of the changes in this release focus on getting from zero to a running app faster: scaffold a fresh WinUI project with a single command, search real WinUI controls and samples without leaving the terminal, and run your app straight from a .csproj<\/code> with no manual build step first. It also adds cloud-based artifact signing, sparse-package workflows, and agent-friendly UI recordings. Grab it with winget install Microsoft.WinAppCLI<\/code>, or head to the repo<\/a> for npm and other install options.<\/p>\n

Get started with the Windows App Development CLI<\/a><\/div><\/p>\n

Here’s a tour of the highlights.<\/p>\n

\u2728 Scaffold a New App with winapp new<\/code><\/h2>\n
\n

The new winapp new<\/code> command creates a WinUI 3 app from the official Windows App SDK dotnet new<\/code> templates. It installs (and offers to update) the template pack for you, so you don’t have to hunt for the right NuGet or workload first. It’s interactive by default, allowing you to select a template and name your app, and falls back to sensible defaults in CI and other non-interactive shells.<\/p>\n

# See every template available in your installed pack\r\n winapp new --list\r\n \r\n # Create a blank WinUI 3 app (the default template)\r\n winapp new --name MyApp\r\n \r\n # Start from a richer template, such as a NavigationView or MVVM app\r\n winapp new --name MyApp --template winui-navview\r\n winapp new --name MyApp --template winui-mvvm<\/code><\/pre>\n<\/div>\n
\n
Templates include a blank app (winui<\/code>), winui-navview<\/code>, winui-tabview<\/code>, an MVVM starter (winui-mvvm<\/code>), a class library (winui-lib<\/code>), and a packaged unit-test app (winui-unittest<\/code>). The list is read live from the pack you have, so --list<\/code> always reflects your version. For reproducible scaffolding across machines, pin the pack with --template-version 1.2.3<\/code>, or take the newest with --template-version latest<\/code>.<\/p>\n
\"Image<\/a><\/p>\n
Where winapp init<\/code> adds packaging and identity assets to an existing<\/em> project, winapp new<\/code> is the entry point for creating a new one.<\/p>\n<\/div>\n
\ud83d\udd0e Find Real WinUI Code with winapp find-ui<\/code><\/h2>\n
\n
Sometimes you know the control you want but not how to wire it up. winapp find-ui<\/code> searches real, working WinUI samples from the WinUI 3 Gallery<\/a> and the Windows Community Toolkit<\/a>, and hands you copy-pasteable XAML and C#. It’s designed to be great for AI agents and humans.<\/p>\n
# Search by intent, returning matching controls with scenario ids \r\nwinapp find-ui \"tabbed layout\" \r\n\r\n# Narrow to a single source \r\nwinapp find-ui \"settings card\" --source toolkit \r\n\r\n# Pull the full XAML + C# for a specific scenario \r\nwinapp find-ui --id gallery-tabview-1<\/code><\/pre>\n<\/div>\n
\n
The workflow is two steps: search compactly to find the right control and its scenario ids, then fetch the complete code with --id<\/code>. The corpus is cached per-user after the first run (refreshed at most weekly, or on demand with --refresh<\/code>). A third source, the C#-only ReactorGallery<\/a>, is opt-in via --source reactor<\/code> for MVU\/Reactor projects.<\/p>\n<\/div>\n
\"Image<\/a><\/p>\n
\ud83d\ude80 Run Straight from a .csproj<\/code><\/h2>\n
\n
winapp run<\/code> now has a project mode<\/strong>. Point it at a .csproj<\/code>, a .sln<\/code>\/.slnx<\/code>, or a directory containing one, and it builds the project and<\/em> launches it with package identity. There’s no separate dotnet build<\/code> step and no digging for the right output folder. It works for both packaged and unpackaged WinUI apps, and the mode is chosen automatically from your input.<\/p>\n<\/div>\n
\n
# Build and run the project in the current directory (like dotnet run)\r\nwinapp run\r\n\r\n# Or point at a specific project\r\nwinapp run .\\src\\MyApp\\MyApp.csproj\r\n\r\n# Pick a configuration\/runtime and pass MSBuild properties through\r\nwinapp run . -c Release -r win-arm64 -p WindowsPackageType=None<\/code><\/pre>\n
Project mode maps familiar options straight to MSBuild: -c\/--configuration<\/code>, -r\/--runtime<\/code>, -f\/--framework<\/code>, --arch<\/code>, --no-build<\/code>, --no-restore<\/code>, and -p\/--property<\/code>. The existing folder mode is unchanged: pass a build-output folder and it registers a loose-layout package exactly as before. (Run with --verbose<\/code> if you ever want to see which mode was chosen and why.)<\/p>\n<\/div>\n
\"Terminal<\/a><\/p>\n
\ud83d\udd0f Cloud Signing with winapp az-sign<\/code><\/h2>\n
\n
The new winapp az-sign<\/code> command code-signs an exe, MSIX, or MSIX bundle using Azure Trusted Signing<\/a>, a cloud-managed signing identity, so no private key (PFX) ever lives on the local machine<\/strong>. It uses Azure’s standard credential chain, which makes it a natural fit for CI: an azure\/login<\/code> session, OIDC, or a managed identity are all honored automatically.<\/p>\n<\/div>\n
\n
# Interactive: discover and select subscription, account, and profile\r\nwinapp az-sign .\\app.msix\r\n\r\n# Fully specified, no prompting (ideal for CI\/CD)\r\nwinapp az-sign .\\app.msix --subscription <sub-id> --resource-group <rg> --account <account> --profile <profile>\r\n\r\n# Reuse an existing metadata.json (skips resource discovery)\r\nwinapp az-sign .\\app.msix --metadata-file .\\metadata.json<\/code><\/pre>\n
Passing all four discovery flags (--subscription<\/code>, --resource-group<\/code>, --account<\/code>, --profile<\/code>) lets az-sign<\/code> validate resources with direct reads instead of listing them, so a least-privilege CI principal scoped to just that certificate profile is enough.<\/p>\n<\/div>\n
\"Terminal<\/a><\/p>\n
\ud83d\udce6 Sparse Packaging Support<\/h2>\n
\n
You can now give package identity to an existing<\/em> desktop app, so it can use notifications, background tasks, or other identity-gated APIs, without converting it to a full MSIX. v0.6.0 adds an end-to-end sparse packaging<\/strong> workflow across three commands.<\/p>\n<\/div>\n
\n
# 1. Generate an identity-only sparse manifest for an existing exe (no SDK install)\r\nwinapp init --exe .\\bin\\Release\\net8.0-windows\\MyApp.exe --sparse --use-defaults\r\n\r\n# 2. Pack the sparse manifest into an identity-only .msix\r\nwinapp pack .\\sparse\\appxmanifest.xml\r\n\r\n# 3. Link the exe to its sparse identity package\r\nwinapp embed-identity .\\bin\\Release\\net8.0-windows\\MyApp.exe<\/code><\/pre>\n
winapp init --sparse<\/code> writes an identity-only appxmanifest.xml<\/code> (plus placeholder assets) and skips all SDK\/package installation, since sparse identity packages have no SDK dependencies. winapp pack<\/code> now accepts that manifest directly to build the identity .msix<\/code>, and winapp embed-identity<\/code> connects the exe to it. See the Sparse Packaging Guide<\/a> for the full walkthrough.<\/p>\n<\/div>\n
\"Image<\/a><\/p>\n
\u26a1 Other Notable Changes<\/h2>\n