WPF Hot Reload Is Here: Edit Your XAML and Watch It Update Live in Rider

Sasha Ivanova

WPF Hot Reload is now available in Rider, starting with the 2026.2 EAP 2 build. You can edit your XAML while your app is running under the debugger and see the changes immediately, with no rebuild, no restart, and no losing your place in the application. Together with the C# Hot Reload support that’s already in Rider, this completes the Edit and Continue workflow for WPF.

This one has been a long time coming, and we want to be straight about that. The request for WPF Hot Reload is one of the most upvoted issues in Rider’s entire history. We read every word of your comments, and the feature we’re shipping today is shaped directly by that feedback. 

A quick, honest note before we go further: this is a beta. The surface area of WPF is large, and some scenarios are not covered yet. We’ll lay those out plainly below so you know exactly what to expect. 

What WPF Hot Reload does

When you’re running a WPF app under the Rider debugger, you can now modify your XAML and have the saved changes reflected in the live, running application. Adjust a margin, restyle a button, tweak a DataTemplate, change a color, rework a layout – then save, and the UI updates in place. The application keeps its current state. You don’t need to navigate back through five screens to get to the view you were working on. You don’t have to rebuild. You just keep iterating.

Why this matters for the way you work

WPF UI development has a natural rhythm: Change something, see how it looks, adjust. Without Hot Reload, that rhythm keeps getting interrupted by a rebuild and a click-path back to the screen you were on. A few situations make that friction especially frustrating, and they are unfortunately not uncommon.

Large, long-lived WPF applications. For many teams, WPF isn’t legacy. It’s the present and the roadmap, with a decade or more of active development ahead across applications maintained by many developers at once. In a codebase like that, UI iteration speed isn’t a nicety; it compounds across every developer, every day. Hot Reload takes the most repetitive loop in WPF UI work – the change, rebuild, navigate back, and check cycle – and collapses it.

Applications with complex UI structures. This is where it gets interesting. Hot Reload has held up across genuinely non-trivial setups, including XAML resource dictionaries that hold control templates for custom controls in a shared WPF library. That’s exactly the kind of structure that tends to be fragile under hot-reload implementations elsewhere. If your UI is built from layered styles, templated custom controls, and shared resource dictionaries, there’s a good chance Hot Reload was a crucial missing piece of your workflow.

Dual-IDE setups. It’s common for teams to run Rider for most of their work while keeping Visual Studio open specifically for the live XAML loop. Maintaining two IDEs for one task is friction nobody wants. Hot Reload removes the need to keep switching, and for a lot of developers, it’s the only remaining reason to keep a second IDE installed.

Supported target frameworks

The current EAP build supports the latest versions of .NET and .NET Framework. net9.0-windows and net10.0-windows work as expected, and .NET Framework targets are supported as well.

How to try it

1. Download Rider 2026.2 EAP 2 or later.
2. Open your WPF project and start a Debug session from Rider.
3. Edit and save your XAML changes, whether styles, templates, layout, or resources.
4. Watch the running app update in place.

That’s the whole loop. No extra configuration, no separate mode to enable.

Known limitations

Here’s the part worth reading carefully: These are the cases where Hot Reload won’t apply a change in place today, along with possible workarounds. For some of these limitations, we don’t have any immediate plans for development, while others will be resolved in upcoming releases. Here is where the beta stands now.

• Adding, removing, or updating NuGet packages. Restore packages, then restart the debugging session.
• Adding new controls, windows, pages, or other files to your project while the app is running. Restart the debugging session to pick them up.
• Changing the root type or x:Class of an already-loaded XAML file (for example, turning a Window into a Page). 
• Making changes to runtime-created resources or runtime-switched theme dictionaries. Restart the debugging session to apply them.
• Adding new WPF class members that rely on static registration, such as a DependencyProperty, an attached property, or a RoutedEvent. Note: This only applies when registration happens in a static field initializer; assigning the field later in a method may also work.
• Adding new x:Name values in XAML. This one is partial: The XAML update itself is applied live, but the new names only become available from your C# code-behind after you restart the debugging session.
• Changing animations started by one-time triggers, such as an EventTrigger on Loaded. The updated animation won’t restart until the view is loaded again. 

Help us prioritize 

Most of the limitations above are tracked in YouTrack with plans to address them in upcoming releases. Each has its own ticket where you can upvote and add details from your setup. The more signal we have on which ones are blocking your work, the easier it is to prioritize them:

• [RIDER-138349] Hot Reload after Attach to Process
• [RIDER-138659] Changes to runtime-created resources or runtime-switched theme dictionaries
• [RIDER-138874] Adding new WPF class members that rely on static registration
• [RIDER-138348] Changing animations started by one-time triggers

A few scenarios sit further out, including Hot Reload after attaching to an already-running process. These require a bit more research before we can commit to a particular approach in implementation. If your architecture relies on one of those, please open a ticket with concrete repro details from your real setup.

Tell us how it goes

WPF Hot Reload in Rider exists because developers repeatedly and specifically told us what they needed, so the best thing you can do now is keep that feedback coming. Try it on your real projects, not just a sample, and tell us how it’s working for you here in the comments, over on X, or via our issue tracker.

We’re going to keep expanding framework coverage and chipping away at the limitations above through the EAP cycle and beyond. Thanks to everyone who voted, commented, and waited, and welcome to everyone trying this for the first time.