.NETpad 2025: WinUI 3 is the Way Forward (Premium)

I've spent the past few weeks--OK, the past few months--focusing on the Windows App SDK and WinUI 3, learning the basics of data binding, and trying to map that to a more complex app architecture that supports multiple tabs and documents. After all that time and effort, I still have so many questions and so many unresolved issues. But one thing is quite clear to me. If I'm truly serious about modernizing this app, it needs to happen in the Windows App SDK/WinUI 3, and for all kinds of good reasons.

And so, for now, at least, I must bid adieu to the Windows Presentation Foundation (WPF). It's just too primitive, and though I love that it's finally getting some attention from Microsoft after years of neglect, it will never measure up to WinUI 3 when it comes to creating a modern app for Windows 11. I tried. I really did. And I may try again in the future, if I can ever figure out this mess. But for now, at least, I'm moving on. And I'm taking my app with me.

Why?

If I were creating a traditional, single-document version of .NETpad, WPF would be ... OK. Not perfect. But OK. WPF mostly supports the Windows 11 look and feel, and you can customize the title bar area with a few difficulties, creating a modern-looking app. There are a few unsupported controls and some other issues. But it's mostly possible.

But in working with the Windows App SDK and WinUI 3, I immediately saw difficulties but also the benefits. There are several advantages inherent to this framework that are unavailable or difficult or impossible to reproduce with WPF.

The most important thing for a multi-document/tab app is, obviously enough, the tabs. WinUI 3, as I'll now call it for simplicity's sake, provides a TabView control with all the features a tabs-based app needs, including features that are not available in the WPF TabControl, like a tab strip header area for the app icon, a tab strip footer area that can be used as the app window drag area, custom "Close tab" button behaviors, and an "Add new tab" button.

And then more advanced features like the ability to drag and rearrange tabs and even tear off a tab to create a new app window.

I could replicate most of that in WPF with a bit of work. But the most crucial feature built into TabView, perhaps, is what I think of as tab overflow. That is, as the user adds more and more tabs, the app runs out of space to display them, and so it automatically creates the "Scroll tab list backward" and "Scroll tab list forward" carets and handles tab sizing. This is not possible in WPF, and I never found an acceptable alternative or workaround.

But it's not just that.

Throughout my .NETpad modernization efforts, I've had to create my own custom dialogs because WPF doesn't support the Content dialog that's native to Windows and is used for confirmation dialogs of all kinds. I created two different Content dialog types for .NETpad over time, and they're needed for several dialogs, including Auto Save...