winui-code-review

When to Use

Run a code review after the app builds and before committing. This catches quality issues that aren't build errors and aren't visible in UI tests — patterns that compile and run but are wrong, fragile, or slow.

How to Review

Read through the project's XAML and C# files and check each section below. For analyzer setup, see winui-dev-workflow; if it isn't installed, tell the user its checks didn't run.

Before reporting an API mismatch or recommending a replacement, verify it against the restored app project's references with CLI 0.7+ winapp find-api, for example winapp find-api members NavigationView --filter selected --json --project-dir <app-project-dir>. See winui-design for batch property checks and project selection; machine-SDK results are not proof of app-package availability.

The analyzer catches a curated set of WinUI 3 / Windows App SDK issues with categorized 4-digit IDs:

• WUI0xxx — UWP → WinUI 3 API compatibility (UwpXamlNamespace, Window.Current, CoreDispatcher, GetForCurrentView)
• WUI1xxx — Migration-table data-driven hints (UWP API has WinAppSDK equivalent, no equivalent, feature-area hint)
• WUI2xxx — Runtime / layout / XAML pitfalls (raw TabView content, nullable binding paths, ineffective binding modes, null Converter, missing AutomationId, attached-property syntax)
• WUI3xxx — MVVM patterns (old [ObservableProperty] field syntax)
• WUI4xxx — Interop (WebView2 not initialized, removed ONNX Runtime GenAI APIs WUI4101-WUI4103)

Use the installed package's diagnostic help links for rule details. Check inherited x:DefaultBindMode and event/command/converter exceptions before treating an omitted mode as a defect. Fix root causes; any justified false-positive suppression must be narrow and documented, not a blanket NoWarn policy. Keep IL/CsWinRT warnings enabled as well; the WinUI analyzer does not replace AOT/trim analysis.