Microsoft’s winapp CLI just took a meaningful step toward making Windows app packaging and identity less painful for cross-platform and .NET developers — and v0.2’s changes show this tool is starting to behave less like an experiment and more like a practical developer utility you can drop into everyday workflows. (
devblogs.microsoft.com)
Background / Overview
The
Windows App Development CLI (winapp) launched in public preview as Microsoft’s attempt to unify a number of repetitive, error-prone tasks around MSIX packaging, manifest management, certificates, and the tricky concept of
package identity into a single command-line surface. The original promise was simple: reduce a multi-step setup to a single, reproducible command that works across frameworks — Electron, .NET (WinUI/WPF/WinForms), C++/CMake, Flutter, Rust and more — and make packaging and debugging requiring Identity fast and predictable.
Version
v0.2, announced March 2, 2026, addresses a long list of community requests. The release adds
first-class .NET project support,
manifest placeholders to avoid hard-coded executable names, a
winapp store subcommand that proxies the Microsoft Store Developer CLI, a cleaner help UX and error handling, and a handful of packaging and asset-management refinements. That mix targets both the day-to-day friction most Windows devs hit and gaps that cross-platform developers found particularly painful. (
devblogs.microsoft.com)
What’s new in v0.2 — quick summary
- First-class .NET project support: run
winapp init in a folder with a .csproj and winapp will configure TargetFramework/Windows SDK versions, add required NuGet references, and generate appxmanifest and Assets scaffolding. (devblogs.microsoft.com)
- Manifest placeholders: Visual Studio-style tokens like
$targetnametoken$ and $targetentrypoint$ are now supported and resolved at packaging time — eliminates fragile hard-coded exe names. (devblogs.microsoft.com)
- Microsoft Store Developer CLI integration:
winapp store <command> proxies to the msstore tool, auto-downloading the msstore binary on first use so you don’t have to install it separately. (devblogs.microsoft.com)
- Improved help & error messages: grouped help output, and cleaner single-line error messages with a
--verbose option for diagnostics. (devblogs.microsoft.com)
- Packaging and asset improvements:
winapp pack no longer pollutes source folders, better resources.pri inclusion, discovery of qualified assets like Logo.scale-100.png, and new commands for external catalogs and package identity management. (devblogs.microsoft.com)
These changes are practical and tactical — not flashy — but they target the real churn that slows down packaging and developer inner loops.
Deep dive: first-class .NET project support
What it does for you
Running
winapp init in a folder that contains a .csproj now:
- Validates and updates the project’s TargetFramework to target the correct Windows SDK.
- Adds NuGet package references such as WindowsAppSDK and build-tool packages directly into the .csproj.
- Generates an appxmanifest.xml and an Assets folder with the expected images and resource scaffolding. (devblogs.microsoft.com)
This eliminates the previous workaround of maintaining a separate YAML-based config for .NET projects and aligns the workflow more closely with how Visual Studio structures .NET apps. The winapp team explicitly removed the automatic generation of winapp.yaml for detected .csproj projects — winapp config now lands where .NET developers expect it: inside the project file. (
devblogs.microsoft.com)
Why it matters
- For .NET developers (WinUI 3, WPF, WinForms, console apps), the painful manual edits to project files, manifest XML, and the hunt for correct NuGet packages become automatable. That lowers onboarding friction for teams that don’t want to rely on Visual Studio’s GUI or prefer VS Code/CI-driven workflows. Independent coverage and early reviews from the community note the same: making winapp a first-class citizen for .NET removes an artificial barrier to packaging.
Caveats and gotchas
- The tool edits project files automatically. Teams that keep rigid project-file templates or rely on custom build pipelines should audit the changes
winapp init performs in a branch before merging. The release notes stress this behavior change and point to the .NET guide for hybrid workflows. (devblogs.microsoft.com)
- Because v0.2 now skips winapp.yaml for .NET projects, any automation that previously relied on a shared winapp.yaml file will require updates. This is a breaking-but-documented change: plan for it in CI and contributor docs. (devblogs.microsoft.com)
Manifest placeholders: small feature, big ergonomic win
Packaging manifests historically hard-code executable names and entry points, which breaks easily across build configurations (Debug/Release), CI runners, or multi-OS build pipelines. v0.2 supports Visual Studio-style manifest tokens —
$targetnametoken$ and
$targetentrypoint$ — which the CLI resolves at pack time. That means a single manifest can be portable across environments and you can avoid fragile string edits or post-processing steps. (
devblogs.microsoft.com)
Benefits at a glance:
- Easier sharing of manifests across branches and CI agents.
- Fewer copy-and-paste mistakes in appxmanifest.xml.
- Cleaner multi-configuration support for teams juggling many target architectures or packaging flows.
This feature is straightforward but addresses a frequent source of build-time burnout, especially for smaller teams or open-source projects that need a single manifest to work on multiple machines. (
devblogs.microsoft.com)
winapp store: msstore CLI integration and the winget question
v0.2’s
winapp store subcommand acts as a
proxy for the Microsoft Store Developer CLI (msstore): when you run
winapp store <args>, winapp downloads the msstore binary on first use and forwards your arguments. Microsoft designed this as convenience: no separate msstore install step for developers who already use winapp. (
devblogs.microsoft.com)
How this overlaps with winget and why it matters
- Windows Package Manager (winget) is a general-purpose package manager for Windows desktop apps; it can install many apps from multiple sources, including the Microsoft Store catalog. The Microsoft Store Developer CLI (msstore) focuses on publishing and store-specific operations and runs cross-platform for Partner Center workflows. The new
winapp store bridge is primarily a developer convenience that surfaces store-specific developer operations from inside the winapp experience.
- Expect some confusion: winget remains the broader tool for end-user discovery and system-level automation, while msstore and the
winapp store proxy focus on developer tasks like publishing, uploading packages, and partner-center interactions. Coverage across trade outlets notes the overlap and advises choosing the tool that fits your automation and publication goals.
Practical takeaways
- If your workflow involves publishing and Partner Center automation, msstore (and thus
winapp store) is useful. If you want wide system-wide package automation and updates on fleets, winget likely remains your go-to. The winapp store integration is a useful shortcut, not a wholesale replacement of other Windows package tooling.
Packaging, assets, and CI/CD: less friction, cleaner outputs
v0.2 makes several pragmatic improvements to the packaging flow:
winapp pack now uses a temporary directory instead of modifying your source tree; that prevents generated artifacts from leaking into source commits. (devblogs.microsoft.com)- Asset discovery improved so qualified asset names (e.g., Logo.scale-100.png) are recognized and included in resources.pri properly; this reduces missing-icon problems and taskbar unplated-icon issues. (devblogs.microsoft.com)
- The
manifest update-assets command now updates all assets referenced in the manifest, which simplifies regenerating scaled assets from a single source image. (devblogs.microsoft.com)
These changes are intentionally tactical: they reduce the “last mile” work of packaging and make the CLI more CI-friendly. Use the GitHub / Azure DevOps actions Microsoft published to install winapp in CI environments so builds are reproducible.
Identity, certificates and security implications
Identity and signing are the core of MSIX and Windows App security. Winapp’s debugging helper
create-debug-identity is one of its most valuable features: it grants an executable package identity to let developers test APIs that require identity (notifications, Windows AI, certain system APIs) without full MSIX installation. That inner-loop speedup matters.
However, v0.2 introduces a notable
breaking change:
winapp init no longer auto-generates a development certificate. You must now run
winapp cert generate explicitly when you need a dev signing cert. This change tightens behavior but requires build scripts and CI pipelines to include an explicit cert generation step if they previously relied on init to produce it. (
devblogs.microsoft.com)
Security and operational checklist:
- Always review any auto-created certificates for appropriate key usage and lifetime before installing them on build agents.
- For CI/CD pipelines, prefer ephemeral or pipeline-bound certificates with limited scope rather than persistent dev certs in a shared secrets store.
- For enterprise distribution, ensure your MSIX signing workflow aligns with your enterprise signing authority (e.g., Azure Key Vault, Certificate Authority) rather than relying on self-signed dev certs. Official Microsoft docs for MSIX signing and the Store publishing workflow remain relevant here.
Strengths: where winapp v0.2 really helps
- Developer inner loop acceleration: creating package identity without full installation is a dramatic time-saver when testing APIs that require identity.
- Lowered friction for cross-platform devs: Electron, Flutter, and other non-Visual-Studio toolchains get packaging and identity helpers that historically favored Visual Studio users.
- Better CI friendliness: the switch to temporary packaging directories and better asset discovery reduces noisy repository diffs and brittle pack steps. (devblogs.microsoft.com)
- .NET integration aligns with modern .NET workflows: editing project files instead of relying on external YAML placements makes setup predictable for .NET teams. (devblogs.microsoft.com)
Risks, limitations and places to be cautious
- Breaking changes in automation: The removal of automatic certificate generation and the change to NuGet global cache behavior are breaking changes for some tooling. Teams must audit and update scripts. The release notes call these out explicitly. (devblogs.microsoft.com)
- Tooling surface fragmentation risk: Microsoft now ships multiple overlapping CLIs — winget, msstore, and winapp — each with a different focus. That creates potential confusion in teams deciding which tool to standardize on for installs, publishing, and packaging. Expect documentation and training costs as a result.
- Security hygiene: Automating certificate generation is convenient but raises operational questions for CI and enterprise signing. The v0.2 behavior moving certificate creation to an explicit command reduces surprise, but teams must still place strong controls on certs used in pipelines. (devblogs.microsoft.com)
- Preview-stage maturity: winapp is in public preview. As with any preview tooling, API/behavior churn remains possible; lock dependency versions in CI and validate upgrade paths before adopting in production release pipelines. Multiple independent outlets and Microsoft’s own blog stress the preview status and the team’s desire for feedback. (devblogs.microsoft.com)
Recommendations for teams evaluating winapp
- Try it locally first — run
winapp init and review the project file diffs in a feature branch. Confirm the TargetFramework and NuGet edits match your release strategy. (devblogs.microsoft.com)
- Pin versions in CI — use the GitHub/Azure DevOps actions Microsoft published to install a known winapp version in reproducible builds. Validate
winapp pack outputs before changing deployment pipelines.
- Make certs explicit — since v0.2 no longer auto-generates dev certs, add
winapp cert generate to any build scripts that need local signing. Consider using ephemeral pipeline keys or Vault-backed signing in release pipelines. (devblogs.microsoft.com)
- Decide Store vs winget policy — choose which CLI will be the canonical tool for installs vs publication in your org and document it. Use
winapp store for developer-centric store operations; reserve winget for fleet-level install/update automation.
- Audit generated manifests — rely on placeholders like
$targetnametoken$ where appropriate, but validate edge cases (multi-exe bundles, multiple entry points) manually before publishing. (devblogs.microsoft.com)
The broader picture: what this means for Windows app development
Winapp is part of a recent push by Microsoft to make modern Windows APIs and packaging more accessible outside of Visual Studio’s traditional ecosystem. It joins other moves — the Windows App SDK changes, msstore CLI, and the ongoing evolution of the Windows packaging story — that together lower barriers for cross-platform authors who historically avoided deep Windows integration for fear of packaging complexity. If Microsoft follows through on iterative improvements, winapp could become the canonical CLI for Windows packaging in multi-toolchain environments.
At the same time, caution is warranted. Multiple overlapping CLIs and preview-stage tooling mean fragmentation, and breakage is still plausible. For enterprises and production release pipelines, the prudent path is measured adoption: experiment, create reproducible CI templates, and harden signing workflows before moving to production distribution.
Conclusion
Windows App Development CLI v0.2 is a practical, community-driven update that addresses the single biggest complaint I’ve heard since winapp’s public preview: developers wanted
less friction getting identity, packaging, and manifests right — especially from non-Visual-Studio toolchains. By adding
first-class .NET support, manifest placeholders,
msstore proxying and a batch of small but meaningful packaging fixes, Microsoft has made winapp significantly more usable for real-world developer workflows. (
devblogs.microsoft.com)
If you’re a .NET, Electron, or Flutter developer building for Windows, evaluate v0.2 in a branch this week: the productivity wins for debugging and packaging are tangible, but you should also plan for the breaking changes to cert generation and NuGet cache behavior. Adopt conservatively in CI, pin the CLI version, and treat the tool as a way to simplify the last mile of Windows packaging — not as a drop-in replacement for your release signing and store-publishing guardrails. (
devblogs.microsoft.com)
Happy packaging — and if you try it, test the
winapp init diff and the
create-debug-identity loop: those two commands are where you’ll first feel the benefit.
Source: Thurrott.com
Windows App Development CLI Updated with .NET Project Support, More