AI-assisted WPF migration works when you combine three things: an AI agent with access to a documentation MCP for grounded API knowledge, a runtime MCP that exposes the running app's visual tree for verification, and a human-in-the-loop review at every code-generation step. Code that compiles is not code that works. The agentic dev loop closes that gap.
Why 2025-Style Copilot Rewrites Disappointed WPF Teams
Through 2024 and 2025, the dominant pattern for AI-assisted WPF migration was: paste a XAML file into a chat window, accept the rewrite, run the build, fix what breaks. Where this worked, it worked for the easiest 30 percent of files: namespace swaps, simple control mappings, basic binding rewrites. Where it failed, it failed silently. The build would succeed and the page would load with wrong layout, missing data, or a binding chain that exploded at runtime.
The root cause was structural. The agent had no way to confirm that its output behaved correctly. It could check syntax. It could not check semantics.
Two industry shifts in 2026 changed the math:
- Microsoft shipped GitHub Copilot Modernization, a Visual Studio agent that supports WPF as a first-class project type with upgrade paths from .NET Framework to .NET 8 or later.
- The Model Context Protocol matured to the point where frameworks could expose both their documentation and their running application state to AI agents. Uno Platform shipped two MCP servers built on this idea.
The result: a migration loop that is no longer "agent guesses, human catches the regressions." It is "agent generates, agent verifies against the running app, human reviews."
The Three-Layer Pattern
Every credible AI-assisted WPF migration in 2026 has three layers. You can run them with different tools, but you cannot skip any layer and ship reliably.
Layer 1: Documentation MCP Server
The agent needs grounded, current API knowledge. Without it, the agent confabulates: it generates plausible WinUI XAML that does not compile against the current Microsoft.UI.Xaml surface, or invents control properties that have not existed since UWP.
The Uno Platform MCP gives AI agents access to current Uno Platform docs, API references, control compatibility tables, and migration patterns. Microsoft's own docs MCP serves the same role for the broader .NET surface.
Layer 2: Runtime MCP Server
The agent needs to inspect the running migrated app, not just the source. The Uno App MCP connects to your launched application and exposes the live visual tree, control properties, screenshots, and input simulation as MCP tools.
- Walk the visual tree and confirm every expected control was rendered
- Read effective property values (foreground, alignment, data context type) on each control
- Capture a screenshot for visual diff against the original WPF render
- Drive input (click, text input, navigation) and assert post-action state
The agent that wrote the code can now check whether the code actually behaves. That is what runtime verification means in practice.
Layer 3: Human-in-the-Loop Review
The agent owns the mechanical translation. The human owns three things the agent cannot reliably own:
- Architectural intent. Which screens get rewritten vs. wrapped. Which singletons become DI services. Which P/Invoke calls become abstracted platform interfaces.
- Edge-case correctness. Threading subtleties around
Dispatcher, ordering of resource-dictionary merges, lifecycle hooks the agent has not seen in training data. - Visual judgment. A diff that is "close enough" for an agent may be a regression a designer would catch in two seconds.
Skipping the human review layer is how you ship a migration that builds, runs, and quietly broke three workflows.
A Worked Agentic Loop
1. DEFINE You: "Migrate Settings.xaml from WPF to Uno.
Preserve layout, keep bindings, target Windows + Wasm."
2. PLAN Agent: queries Uno Platform MCP for namespace mappings,
control parity, binding-syntax differences. Returns a plan.
3. GENERATE Agent writes SettingsPage.xaml and SettingsPage.xaml.cs.
Saves to disk. Runs dotnet build. Build passes.
4. DEPLOY Agent runs the app under the App MCP. App MCP reports
the running process and exposes the visual tree.
5. VERIFY Agent queries the App MCP:
- Walks the visual tree of the Settings page
- Reads each TextBox.Text and CheckBox.IsChecked
- Captures a screenshot
Compares vs. expected state.
6. ITERATE Discrepancy: a CheckBox bound to ViewModel.UseDarkMode
is unchecked. Agent inspects binding chain via App MCP,
finds mode regressed from TwoWay to OneTime.
Agent patches the XAML, re-runs build + verify. Pass.
7. REVIEW Human reviews the diff in the PR. Confirms intent, merges.The loop is iterative. The runtime verification step (5) is what makes it agentic instead of generative.
Where Microsoft's Copilot Modernization Fits
GitHub Copilot Modernization is Microsoft's first-party agent for upgrading .NET projects. For WPF teams that want to stay on WPF and just modernize the runtime, Copilot Modernization is the right tool.
For WPF teams going cross-platform, Copilot Modernization handles the .NET runtime upgrade. The XAML-to-XAML translation, control mapping, and runtime verification fall outside its scope, which is where the docs MCP plus runtime MCP loop fits in.
These tools compose. A typical WPF-to-Uno path uses Copilot Modernization for .NET Framework to .NET 9 first, then the agentic loop for the cross-platform translation.
What the Loop Does Well, and What It Does Not
| Migration Task | Agent Coverage | Human Still Required |
|---|---|---|
Namespace swap (clr-namespace: to using:) | High (~100%) | Spot-check imports |
Binding syntax ({Binding} to {x:Bind}) | High with docs MCP | Confirm Mode, UpdateSourceTrigger |
DynamicResource to ThemeResource | High | Confirm theme dictionary structure |
| Standard control mapping | High for parity controls | Manual port for non-parity controls |
| Third-party control replacement | Low | Architectural decision per control |
Threading (Dispatcher to DispatcherQueue) | Medium | Concurrency review |
| P/Invoke abstraction | Low | Design platform-interface layer |
| Visual fidelity check | Medium (screenshot diff) | Designer review |
| Final UAT | None | Human owns |
The honest framing: AI agents handle the mechanical 60 to 70 percent. The remaining 30 to 40 percent is where human judgment earns its place.
Tools You Can Install Today
- An IDE-side agent: GitHub Copilot, Claude Code, Cursor, or Visual Studio Copilot
- The Uno Platform MCP, configured as an MCP server in your agent
- The Uno App MCP, running locally against your launched migrated app
- Community tier of Uno Platform Studio (free): Hot Reload, Toolkit, MCP (unlimited), and App MCP (Interactivity)
- Optional: Uno Platform Studio Pro ($39/month per dev): Hot Design, Hot Design Agent (Preview), and App MCP Context features
- Optional: GitHub Copilot Modernization for the upstream .NET Framework to .NET 9 step
What to Verify Before You Ship
- Build and run on every target. Windows, plus the platforms the migration unlocks. The App MCP can drive a smoke test on each.
- Visual diff vs. the WPF original. Screenshot diff is necessary but not sufficient. A designer pass on at least the high-traffic screens.
- Binding correctness. Check
Mode, default values, and update triggers on inputs. - Threading. Any
Dispatcher.Invokeported toDispatcherQueue.TryEnqueueshould be reviewed for ordering assumptions. - Platform-specific paths. Every
#if WINDOWSor P/Invoke call should be reviewed for cross-platform abstraction needs. - Tests. Existing unit tests for ViewModels should pass without modification. UI tests need a re-pass on the new visual tree.
Install the App MCP, point it at your in-progress Uno port, and run a single verification cycle on one migrated screen. The setup guide is in the Uno Platform MCPs documentation, and the full agentic-loop walkthrough is in the agentic dev workflow blog post.
Subscribe to Our Blog 
Subscribe via RSS
Back to Top