wpf-to-winui-migration

name	wpf-to-winui-migration
description	Use when migrating WPF source projects, classic .NET Framework WPF projects, XAML, dependency properties, commands, resources, or interop to WinUI 3 or Uno.

WPF To WinUI Migration

Use this skill for WPF source migrations, including SDK-style WPF projects, old-style .NET Framework WPF projects, and mixed evidence that must not be silently treated as Avalonia.

Workflow

1. Pin the source framework:

dotnet run --project src/MigrateToWinUI.Cli -- analyze <sln|csproj|dir> --source wpf --target both --format json --report out/migration/wpf-analysis.json

2. Generate a migration plan and dashboard:

dotnet run --project src/MigrateToWinUI.Cli -- plan <input> --source wpf --target both --format md --out out/migration/wpf-plan.md
dotnet run --project src/MigrateToWinUI.Cli -- detail <input> --source wpf --target both --format md --out out/migration/wpf-dashboard.md

3. Preview rewrites:

dotnet run --project src/MigrateToWinUI.Cli -- convert <input> --source wpf --target winui3 --dry-run --preview out/migration/wpf-preview.txt

4. Compose target projects only after reviewing manual blockers:

dotnet run --project src/MigrateToWinUI.Cli -- compose <input> --source wpf --target both --out out/target-projects --project-name MigratedWpfApp --clean --allow-manual-review

Review Focus

• WP2U030x: dependency properties, routed events, commands, validation/coercion metadata.
• WP2U040x: triggers, templates, resources, visual states.
• WP2U060x: platform services, windowing, dialogs, clipboard, file access.
• WP2U070x: drawing, media, interop, HwndHost, printing/documents.
• MTW0001: mixed Avalonia/WPF evidence. Ask for explicit --source.

Guardrails

• Do not claim WPF trigger/template conversions are safe unless the rule says so.
• Keep Window/Page shell decisions product-specific.
• Treat old-style .NET Framework project diagnostics as migration inventory, not failures by themselves.