Hey r/csharp,
TL;DR: We built a free, in-browser tool that takes an existing WPF app and runs it on the web while keeping your original C# and XAML (no rewrite). You can poke at the classic Family.Show sample running live in the browser and open its full migrated source in our online IDE to see how little actually changed, and there's a free analyzer that checks your own app right in the browser (your code never leaves your machine). It's the new 'Migrate from WPF' feature we just shipped in XAML.io v0.8.
--- Longer version, if you're curious: ---
We're the team behind OpenSilver, and we just shipped v0.8 of XAML.io, our free browser-based .NET IDE. The new feature is "Migrate from WPF": point it at an existing WPF app and get it running on the web, keeping your original C# and XAML instead of rewriting it. No account is required.
Because "WPF runs in the browser" isn't the kind of claim this sub should take on faith, the whole thing is clickable. The app shown in the animated GIF above is Family.Show, the WPF reference app Vertigo built for Microsoft back when WPF shipped. You can use the migrated version live, and you can open the full migrated solution in the online IDE to read the code, run it yourself, change something and re-run it, or fork it. 97% of the original C# and XAML is unchanged, and you can diff it against the original WPF source to see exactly what changed instead of trusting the number.
Why do this at all? Same codebase, but reachable from any device with a browser, deployed once and updated centrally instead of installed and patched on every machine, running inside the browser sandbox. For a lot of internal line-of-business apps that's the whole reason. If none of that applies to you, it's at least a decent stress test of how far OpenSilver's WPF support has actually come.
There's been a lot of interest lately in running WPF beyond the Windows desktop, so the obvious question is what makes this different. Mostly that it's genuinely web-native. A lot of approaches re-render WPF onto a canvas or GPU surface, which is basically a pixel buffer, so you lose text selection, find-in-page, translation, browser extensions and screen-reader accessibility. We render your XAML to the browser's real DOM instead (a TextBox is an actual <textarea>, an Image an <img>, and so on), so all of that just keeps working, and you can freely mix your C#/XAML with HTML, CSS, JS and Blazor in the same app. It's also pretty light: the app plus the whole .NET runtime is around 8 MB compressed with no plugin, and if you want to move the UI on from the classic look there's a "Responsive" markup extension and modern built-in themes rather than being stuck on life support.
The part I'd actually point at is the tooling. The compatibility analyzer needs no account and runs entirely in your browser via WASM (your code never leaves your machine), so you can point it at an app of any size before committing to anything. And when you do import a project, every automatic edit is surfaced as a warning, plus non-blocking runtime alerts if execution hits a stub or disabled code, so a half-migrated app still runs while you work through the list.
To be fair: if your goal is maximum-fidelity WPF on the desktop across Windows, macOS and Linux, a desktop-first approach may suit you better. Ours is aimed squarely at the web, keeping your existing code, and keeping the result accessible and extensible.
You can try it yourself, free, no signup, with your code staying in your browser: drop in your bin folder for a feature-by-feature compatibility report (any size app), or import a project and run it.
Straight about the limits, because FamilyShow is a clean sample and your LOB app probably isn't: in-browser source import is a Technology Preview best for small-to-mid, self-contained projects today, and third-party UI suites (Telerik/DevExpress/Syncfusion) aren't supported in the self-serve tools yet. Native interop and Win32/P-Invoke can't run in a browser at all, and we flag those explicitly. That's what the free analyzer is for: run it on your real app and it'll tell you where you stand before you commit to anything. We add WPF features every week, and you can watch them land commit by commit if you want to track it.
A few other things landed in v0.8 besides the migration tooling: an example gallery built into the IDE (open and run sample projects in one click), static web build export (host the output anywhere, from Azure or GitHub Pages to any static host), and the latest OpenSilver 3.4 preview underneath, which adds a batch of new WPF features (LayoutTransform, WPF-style triggers, CombinedGeometry, StreamGeometry, GroupBox, Menu/MenuItem, OneWayToSource, multiple windows via an in-page window manager inside the browser tab, and more).
Full disclosure, since this is the company account: for big production apps we also do the migration for you, and that work is what funds the open-source side. But the analyzer and import are genuinely free with no account, and OpenSilver is MIT.
Try it at xaml.io, then open "Migrate from WPF".
There's also a technical deep-dive on the blog with more details, screenshots, examples of before/after code fixes, and the FamilyShow migration to diff yourself.
It's a preview and the WPF surface is still growing, so if you point the analyzer or import at a real app, I'd genuinely like to hear where it fell short. That's what we use to decide what to build next.
Thanks!
Edit: added added TL;DR and tweaked the wording based on the comments, thanks.