winapp, makes a meaningful change to the entry path for a WinUI desktop app: a developer can create a project, build it, give it package identity for local testing, and produce an MSIX package without opening Visual Studio. That is not the same as eliminating the Windows development toolchain, nor is it a promise of a finished replacement for every Visual Studio workflow. But for developers who prefer a terminal-first setup, automation, or a lightweight editor, the public-preview tool now covers a useful end-to-end path.
The key distinction is between building an application and integrating it with Windows. The CLI helps with both. It can set up SDK-related requirements, create package manifests and identity, manage development certificates, sign packages, and create MSIX output across several Windows application frameworks. Its newest WinUI creation workflow arrived with WinApp CLI version 0.6.0, so this is a recent capability rather than a mature, long-established alternative.
What “without Visual Studio” really means
The documented workflow does not require the Visual Studio IDE. A developer can use the .NET command line and winapp to scaffold a WinUI project and run it from a project file. That is valuable for several groups:
- Developers who use Visual Studio Code or another editor.
- Teams that want repeatable build and packaging commands in scripts or CI systems.
- Experienced Windows developers who want to inspect and control the project structure rather than start from an IDE wizard.
- Learners who want a smaller initial surface area than a full Visual Studio installation.
There are limits. WinApp CLI does not make the underlying requirements disappear. A WinUI project still needs a supported .NET SDK, a compatible Windows version, and—when using loose-layout package registration—Developer Mode. Nor should public-preview software be treated as an unchanging build dependency: commands, defaults, generated project details, and behavior can change before a final release.
The practical conclusion is straightforward. winapp is a promising terminal workflow for building Windows apps, but teams should pin and test their tooling rather than assume a preview command will behave identically forever.
Prerequisites: the .NET 10 claim needs correction
One common description of this workflow says that .NET 10 or later is mandatory. Microsoft’s documented WinUI C# templates do not support that narrower conclusion. They list .NET 8, .NET 9, and .NET 10 as supported choices. .NET 10 is therefore a valid option, but not the established minimum.
The template documentation also sets two Windows-side requirements relevant to the command-line run experience:
- Windows 10 version 1809, build 17763, or later.
- Developer Mode for registering a loose-layout package.
That last detail matters because winapp run can do more than launch a compiled executable. For a packaged .NET/WinUI project, it can build the project, create and register a loose-layout package, then start the app with package identity. A machine lacking Developer Mode may therefore fail at a point that can look, at first glance, like an application build problem.
Before troubleshooting project code, verify the operating system, Developer Mode, the installed .NET SDK, and the CLI version. Preview tooling makes that basic discipline more important, not less.
Creating a minimal WinUI application
The central scaffold command is:
winapp new --template winui --name HelloKorben --use-defaults
Here, winui selects the default minimal blank XAML WinUI template, --name supplies the project name, and --use-defaults accepts the template’s standard choices. The CLI obtains the necessary template pack on demand. The resulting project is designed with MSIX packaging and package identity support, rather than leaving those concerns as a later manual retrofit.
The relevant C# WinUI template package is a prerelease package, version 0.0.6-alpha. That status is worth taking seriously. A template is not merely boilerplate; it defines project files, package configuration, startup code, and the location where a developer begins changing the UI. Instructions that name a particular XAML file should be treated as specific to the template version actually generated on the machine.
In other words, developers should inspect the newly created project instead of assuming every online walkthrough matches it exactly. The documented CLI determines available templates dynamically from the installed template pack, so file-level guidance can drift as the pack evolves. This is especially relevant when following a simple “change this text to Hello World” example: the concept is stable, but the exact generated file arrangement is a template-version detail.
Build and run: why package identity changes the result
After creation, the core command is:
winapp run
When used in a qualifying project directory, project mode can work directly from a .csproj, a solution, or a qualifying directory. The command builds the app and launches it. For packaged WinUI projects, the important additional behavior is loose-layout registration: Windows sees the launched application as having package identity even though it is being run from its development output rather than installed from a conventional MSIX deployment path.
That is more consequential than a convenient shortcut. Package identity is part of how Windows enables a range of desktop integration points. It supports manifest-based file associations and custom protocol handlers, for example. It is also needed for important identity-gated capabilities, including the common production path for push notifications and some Windows AI functionality.
Developers should not overstate the distinction, however. It would be inaccurate to say that all “native notifications” require package identity. Windows App SDK local app notifications can work in both packaged and unpackaged apps. Push notification scenarios are different: package identity is required for background delivery and COM activation in most production cases. The right question is not “does my app show notifications?” but “which notification delivery and activation model does my app need?”
The same caution applies to choosing a packaged or unpackaged application architecture. Package identity brings meaningful Windows integration, but it also brings manifest and deployment responsibilities. winapp run is useful precisely because it lets developers test the identity-aware path early, before discovering packaging implications at release time.
From a development run to an MSIX package
For distribution-oriented output, WinApp CLI provides winapp pack. The command supports MSIX creation and can generate a development certificate, install that certificate on the machine, and sign the output. It also offers a --self-contained option that bundles the Windows App SDK runtime with the application.
Self-contained and framework-dependent deployment represent a real distribution decision:
- Framework-dependent deployment relies on the Windows App SDK runtime being installed on the user’s machine.
- Self-contained deployment includes the Windows App SDK binaries with the application.
A self-contained package can reduce reliance on a separately installed runtime, but it can also increase the package’s deployment footprint. It is not inherently “better”; it is a choice based on the intended installation environment and operational model.
The documented default MSIX filename pattern uses the package name, version, and architecture:
<name>_<version>_<arch>.msix
Developers should not assume that a newly generated project will necessarily produce a GUID-based package filename. That depends on manifest details, and the available command documentation does not establish such a default for every generated project.
Development certificates are not a public distribution plan
The certificate options can make the first local packaging test pleasantly direct, but they also create one of the most important boundaries in this workflow. A self-signed development certificate is useful in development and controlled testing environments. It is not automatically trusted on other users’ PCs.
For direct distribution beyond a controlled set of machines, Microsoft’s guidance is to use a certificate trusted by a certificate authority. Alternatively, Microsoft Store submissions are signed by Microsoft. This is not a cosmetic requirement: Windows needs a trust chain to verify who signed a package and whether it has been altered.
That has concrete implications for a Windows developer preparing a release:
- Local test package: generating and installing a development certificate can be appropriate for the developer’s own machine.
- Internal pilot: establish how testers will trust the signing certificate before sending them an MSIX file.
- Broad direct distribution: plan for a CA-trusted code-signing certificate and a support process for installation issues.
- Store delivery: account for Store submission requirements and Microsoft’s signing role instead of treating local development signing as the final release mechanism.
Skipping this distinction can turn a successful local winapp pack result into a confusing customer installation failure.
Where the CLI fits—and where Visual Studio still fits
WinApp CLI is best understood as an alternative workflow surface, not a declaration that the IDE is obsolete. The command-line path is particularly attractive when project creation, builds, packaging, and signing need to be scripted. It also lowers the barrier for developers who already work in a text editor and terminal.
Visual Studio can still be a better fit for developers who depend on its graphical debugging, designer-oriented experience, project management features, or familiar Windows development tooling. Those are workflow choices, not proof that the CLI approach is incomplete by definition.
The stronger point is that a Windows app no longer has to begin with an IDE wizard. With a supported .NET 8, 9, or 10 environment, a compatible Windows installation, Developer Mode for loose-layout registration, and a willingness to work with public-preview tooling, a developer can start with one scaffold command and move toward an identity-aware MSIX application from the terminal.
A sensible way to adopt it now
For individual experiments, the path is clear: create the default WinUI app, inspect the generated template rather than relying on stale file instructions, change the UI, and use winapp run to validate the build and identity-aware launch flow.
For production work, adopt it incrementally. Test the exact CLI and template versions in use, keep packaging and signing decisions explicit, and verify installation on clean target machines. Treat --self-contained as a deployment trade-off, not a universal switch. Most importantly, distinguish local notifications from push scenarios and local development certificates from distribution-grade signing.
That approach captures the genuine advantage of WinApp CLI: it makes native Windows app creation and packaging accessible from the command line without requiring Visual Studio, while keeping the platform’s packaging, identity, trust, and deployment realities visible instead of hiding them.