Agent skill

dotnet-winui

Build or review WinUI 3 applications with the Windows App SDK, including MVVM patterns, packaging decisions, navigation, theming, windowing, and interop boundaries with other .NET stacks. Use when building modern Windows-native desktop UI.

Stars 302
Forks 22

Install this agent skill to your Project

npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/catalog/Frameworks/WinUI/skills/dotnet-winui

SKILL.md

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

  1. 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.
  2. Choose packaging model early — packaged (MSIX) vs unpackaged differ materially for deployment, identity, and API access:
    xml
    <!-- Unpackaged: add to .csproj -->
    <WindowsPackageType>None</WindowsPackageType>
    
  3. Apply MVVM pattern with the MVVM Toolkit — keep views dumb, logic in ViewModels:
    csharp
    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;
    }
    
  4. Use x:Bind for compiled bindings — better performance and compile-time checking than {Binding}:
    xml
    <TextBlock Text="{x:Bind ViewModel.Title, Mode=OneWay}"/>
    
  5. Wire DI through Host.CreateDefaultBuilder — register services, ViewModels, and views. Resolve via App.GetService<T>().
  6. Implement navigation service — map ViewModels to Pages by convention. See references/patterns.md for the full pattern.
  7. Handle Windows App SDK features — windowing (AppWindow), custom title bar, app lifecycle, notifications.
  8. Always set XamlRoot when showing ContentDialog — omitting this causes silent failures.
  9. Validate on Windows targets — behavior depends on runtime, packaging model, and Windows version.
mermaid
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

Expand your agent's capabilities with these related and highly-rated skills.

managedcode/dotnet-skills

dotnet-project-setup

Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.

302 22
Explore
managedcode/dotnet-skills

csharp-scripts

Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.

302 22
Explore
managedcode/dotnet-skills

dotnet-pinvoke

Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.

302 22
Explore
managedcode/dotnet-skills

nuget-trusted-publishing

Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.

302 22
Explore
managedcode/dotnet-skills

dotnet-legacy-aspnet

Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.

302 22
Explore
managedcode/dotnet-skills

dotnet-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.

302 22
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results