winui-dev-workflow

Requires WinApp CLI 0.7+.

Create or Open a Project

New app — let WinApp CLI install/update the official templates and scaffold:

winapp new --name <AppName> --template winui-mvvm --template-version latest --use-defaults
cd <AppName>

Run winapp new --list to discover the currently installed template short names. Do not install the template pack separately and do not create the output directory first.

Existing app — read the .csproj to understand:

• <TargetFramework> (e.g., net10.0-windows10.0.26100.0)
• <PackageReference> versions (WindowsAppSDK, CommunityToolkit)
• Project structure and established patterns

Add or Check the Per-App Analyzer

Add the latest stable analyzer to each app project; do not assume a template includes it:

dotnet add .\MyApp.csproj package Microsoft.Windows.SDK.BuildTools.WinUIAnalyzer

Keep PrivateAssets="all" on the reference. It loads in normal CLI, IDE, and CI builds; WinApp CLI does not inject it. If the package is unavailable, continue and tell the user its checks for potential runtime issues did not run. Undo only an incomplete reference added by this attempt; do not remove existing references or hide other restore failures.

For other packages, prefer the latest stable unless the project has a version policy or the user requests a specific version. Before coding API assumptions, use winapp find-api scoped to the restored app with --project-dir <app-project-dir> (or --project <name> in a solution); see winui-design.

Build & Run (JIT Development)

winapp run . --detach --json

For UI testing, see winui-ui-testing, which chooses the execution target itself.

Ordinary winapp run uses the build/JIT path, even with -c Release; it does not validate Native AOT. Use an explicit .csproj when project selection is ambiguous; see winapp run --help for options.

If build fails: Read all errors, batch-fix them in one pass, then rerun the same command.

Native AOT Publish Runs

For intended AOT deployment, set <PublishAot>true</PublishAot> in the app project (it also enables analysis during development); for a one-off trial, pass -p PublishAot=true. --aot publishes rather than builds; choose an --arch runnable on this machine:

winapp run . --aot -c Release --arch <x64|arm64> --detach --json
winapp run . --aot -c Release --arch <x64|arm64> -p PublishAot=true --detach --json

Fix IL/CsWinRT warnings rather than suppressing them. See winui-packaging's references/sourcegen-patterns.md.

Diagnosing Crashes

Run attached with --debug-output and invoke it with mode: "async", then read the same shell. On a WinUI crash, stowed-exception triage surfaces the real XAML error behind an opaque 0x8000FFFF / E_FAIL; add --symbols for richer native frames. The first crash downloads debugger components; set WINAPP_DBGTOOLS_DIR to an existing Debugging Tools for Windows install when offline. --debug-output cannot combine with --json or --no-launch.

Common Errors

Prerequisites

If WinApp CLI is missing or older than 0.7, install or upgrade it using winui-setup without asking (it needs no admin rights) and tell the user. Ask before installing anything that needs admin rights — the .NET SDK, Developer Mode, or the Native AOT toolchain; do not work around them.

Critical Rules

• Keep packaged as the default and use project-mode winapp run for activation.
• Only for an explicitly requested unpackaged/debug experiment, set WindowsPackageType=None; package-identity-dependent APIs may fail and runtime requirements still apply. Do not use this as a silent launch workaround. Preserve the manifest and restore the original packaged setting after the experiment.
• Do not delete Package.appxmanifest.
• ❌ NEVER use AnyCPU — always x64 or ARM64

References

• winui-packaging — release packaging directly from the project; no development registration required.