winui
WinUI 3 and Windows App SDK
Trigger On
- building native modern Windows desktop UI on WinUI 3
- integrating Windows App SDK features into a .NET app
- deciding between WinUI, WPF, WinForms, and MAUI for Windows work
- implementing MVVM patterns in Windows App SDK applications
Workflow
- Confirm WinUI is the right choice — use when modern Windows-native UI, Fluent Design, and Windows App SDK capabilities are needed. For cross-platform, consider MAUI instead.
- Choose packaging model early — packaged (MSIX) vs unpackaged differ materially for deployment, identity, and API access:
<!-- Unpackaged: add to .csproj --> <WindowsPackageType>None</WindowsPackageType> - Apply MVVM pattern with the MVVM Toolkit — keep views dumb, logic in ViewModels:
public partial class ProductsViewModel : ObservableObject { [ObservableProperty] private ObservableCollection<Product> _products = []; [ObservableProperty] [NotifyCanExecuteChangedFor(nameof(DeleteCommand))] private Product? _selectedProduct; [RelayCommand(CanExecute = nameof(CanDelete))] private async Task DeleteAsync() { if (SelectedProduct is null) return; await _productService.DeleteAsync(SelectedProduct.Id); Products.Remove(SelectedProduct); } private bool CanDelete() => SelectedProduct is not null; } - Use x:Bind for compiled bindings — better performance and compile-time checking than
{Binding}:<TextBlock Text="{x:Bind ViewModel.Title, Mode=OneWay}"/> - Wire DI through
Host.CreateDefaultBuilder— register services, ViewModels, and views. Resolve viaApp.GetService<T>(). - Implement navigation service — map ViewModels to Pages by convention. See references/patterns.md for the full pattern.
- Handle Windows App SDK features — windowing (AppWindow), custom title bar, app lifecycle, notifications.
- Always set
XamlRootwhen showing ContentDialog — omitting this causes silent failures. - Validate on Windows targets — behavior depends on runtime, packaging model, and Windows version.
flowchart LR
A["Choose WinUI"] --> B["Select packaging model"]
B --> C["MVVM + DI setup"]
C --> D["Navigation and views"]
D --> E["Windows App SDK features"]
E --> F["Validate on target runtime"]
Key Decisions
| Decision | Guidance |
|---|---|
| Packaged vs unpackaged | Packaged (MSIX) for Store, auto-update, and full API access; unpackaged for simpler deployment |
| x:Bind vs Binding | Always prefer x:Bind — compiled, faster, type-safe |
| MVVM Toolkit attributes | Use [ObservableProperty], [RelayCommand] to eliminate boilerplate |
| Navigation | Convention-based ViewModel→Page mapping via navigation service |
| Theming | Use RequestedTheme on root element; respect system theme by default |
Deliver
- modern Windows UI code with clear platform boundaries
- explicit deployment and packaging assumptions
- MVVM pattern with testable ViewModels
- cleaner interop between shared and Windows-specific layers
Validate
- WinUI is chosen for a real product reason, not defaulted to
- Windows App SDK dependencies are explicit in the project file
- packaging and runtime assumptions are tested on target
- x:Bind is used for compiled bindings throughout
- navigation and ContentDialog both work with correct XamlRoot
- custom title bar renders correctly on Windows 10 and 11
References
- references/patterns.md - WinUI 3 patterns including MVVM, navigation services, DI setup, windowing, theming, dialogs, and lifecycle handling
- references/anti-patterns.md - common WinUI mistakes with explanations and corrections
More from managedcode/dotnet-skills
dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10dotnet-modern-csharp
Write modern, version-aware C# for .NET repositories. Use when choosing language features across C# versions, especially C# 13 and C# 14, while staying compatible with the repo's target framework and `LangVersion`.
10