.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 on, Auto Save off, Save confirmation, and Go to line. And I also used the second of these designs to create my own Message box dialog because WPF doesn’t support that either (it uses an older version that doesn’t look native in Windows 11).

With WinUI 3, I don’t need custom classes and UIs for all those dialogs; I can just use the built-in and native Content and Message dialogs. That’s a lot less code to maintain or even think about it. I’ve already implemented the file operation work–New document, Open document, Save/Save as document–and I use a standard Content dialog in each case if there’s an unsaved document in the app that the user might want to save first. Here, too, is another feature not available to WPF: When this confirmation dialog appears, the main app window is automatically grayed out and unavailable.

WinUI 3 also supports all the modern controls and interfaces that are available in Windows 11, unlike WPF. The most obvious is the ToggleSwitch control that’s used in app settings; WinUI 3 supports it, but WPF uses the older ToggleButton control. Beyond that, there are UIs I’ve not used but now can, like flyouts, pop-ups, and teaching tips. So whether the goal is to just duplicate Notepad, which has been much of the point to date, or to create something unique but also clearly Windows 11-native, as I’m leaning now, WinUI 3 is the better choice. The only choice, really.

I’ve spent much of the past month trying to wrap my head around data binding, a feature of both WPF and WinUI 3 that I still find incredibly confusing, lacking, inconsistent, and difficult to debug. What I’ve ended up doing out of pragmatism is finding something that works and using it as a template of sorts so I can reproduce the functionality as needed elsewhere in the app. This is a bit perilous, however, because I can’t say that I completely understand it yet, and when something works with one data binding but not another, everything comes crashing to a halt so I can figure it out.

All I can do there is keep trying, but it finally occurred to me that I was putting the cart in front of the horse, so to speak, by trying to do not just data binding, but data binding between collections of data (tied to the underlying multiple documents) with collections of dynamically created UI controls (especially the text box associated with each tab/document). That is, I need to start smaller and get this working correctly with just a single document. Which, to be fair, I’ve done. But what I’ve not done in WinUI 3, yet, is the rest of the application. All the commands and menus, the settings interface, find and replace, and so. I’ve been working on the hard stuff. But not the basics.

So, yes, I’m taking a step backward here. I’m recreating .NETpad as it now stands, but in WinUI 3. A single document version of the app, but with all the features of the existing app, and with the basics of multiple tabs and documents built-in. That will make it easier to move to multiple tabs and documents once I’ve recreated the rest of the app.

Beyond data binding, I’m still trying to figure out other aspects of this app that I think are important, including resources and styles. As it now stands, I can’t replicate the two-toned look you see in the top of the Notepad app window. But I keep working on this too.

I’ve also worked across various WPF and WinUI 3 versions of this app on a componentization–or maybe code separation–effort that keeps evolving. In the latest version, which should be the one I push forward with, I have classes for File operations and Document (formerly DocumentTab), and I’m dynamically creating each tab with C# code, rather than using XAML, because I’m associating a menu bar, text box, and status bar with each tab. That work is evolving, and then I’ll have to figure out Find/Replace and whatever else. But first things first.

I will likely have to replace the current WinUIpad project I have in GitHub with this new version, but I will look at that this week. Either way, I’ll make the updated code available so anyone who wants to can follow along with the actual live codebase.

More soon.