What I’ve Learned About C#, Visual Basic, Windows Forms, XAML, and WPF (Premium)

For much of the past year, I’ve been researching Microsoft’s previous-generation developer technologies, in part to chart its history in my Programming Windows series and in part to create the .NETpad application and future projects. I’ve always spent time on this kind of thing, but these efforts have focused my attention in ways that would have never happened otherwise. And I feel like I have a better understanding of Microsoft’s various pushes over time to modernize its core desktop platform and the developer technologies that support it.

My previous understanding of .NET, Visual Basic .NET, and Windows Forms was that Microsoft had, to some, betrayed what made “classic” Visual Basic (through version 6) so great. And that the new environment was so complicated that it alienated the enthusiasts and non-professional developers who had so loved previous versions of the product.

Looking at VB.NET and Windows Forms today, however, I see nothing like that. VB.NET is more modern and professional, as a language, than was its predecessors, yes. But I don’t understand the complaints at all and feel that VB/Windows Forms was—and still is—the logical successor to classic VB. This is a fantastic environment for creating classic Windows applications, and the only thing holding it back in that regard is that Microsoft stopped updating it to support new user experiences and user interface controls. (Witness the issues I had with Task Dialogs and Find/Replace dialogs in .NETpad as an obvious example.)

The real problem with Windows Forms, of course, is that it was the right tool for the 1990s, despite being introduced in the early 2000s. By that point, developers and users had moved on to the web, and while it was laudable that Microsoft had created an environment that combined the sophistication of C/C++ in the new C# language and the RAD capabilities of classic VB in Windows Forms, it just came too late. And by the time Windows Forms had shipped alongside the first version of the .NET Framework, Microsoft was already working on the next big thing.

That next big thing was originally codenamed Avalon and was released years later as the Windows Presentation Foundation (WPF). Unlike Windows Forms, WPF was a major break with the past, as developers didn’t just have to learn a new framework but also a new way of constructing user interfaces. This new declarative approach to UI design utilized an XML-like markup language called XAML (pronounced “Zammel”), which basically worked like a more sophisticated HTML.

XAML was so powerful, it’s still in use today in the Universal Windows Platform (UWP) and Xamarin frameworks, and non-Microsoft developers use XAML/XML-like methods for describing UIs on both mobile and the web as well. (I understand that each XAML implementation differs somewhat, but I’ve not spent much time with UWP or Xamarin yet.)

XAML solves a lot of problems with the static bitmap- and pixel-based methods of laying out application UIs used by older frameworks like classic VB and Windows Forms. But the most obvious, in my experience, is that they allow developers to more easily target the wide variety of displays out in the wild, which have different resolutions (often very high) and pixel densities (also often very high).

XAML also allows UIs to be more dynamic, to flow correctly as the display changes (perhaps by a user resizing a window, or in response to other events), and to incorporate more modern 3D and animation elements, things that were previously available only in games and thus via technologies like DirectX/3D.

Alas, XAML isn’t perfect. For the classic VB, C, or even C# developer, it was (and still is) something new and difficult to learn. And unlike classic VB and Windows Forms, it was no longer possible to use a friendly drag and drop RAD environment to layout windows, dialogs, and controls. (WPF does have a visual designer of sorts, but the performance is terrible, and the experience of creating UI/UX via code is superior; and yes, you can actually drag and drop controls from a toolbox, as before, but with WPF, you’re better off doing so into code, which wasn’t possible in WinForms.)

The WPF learning curve is tough, and while I got up to speed immediately with WinForms, I did struggle with WPF until I figured out that XAML was a lot like HTML and was better interfaced with via code. But there are other issues: Where WinForms lacks some modern features (those Task Dialogs and Find/Replace dialogs I mentioned) earlier, WPF inexplicably lacks some very basic controls and dialogs that even WinForms has, including the Font dialog and the Color dialog. Crazy.

You can actually use the WinForms dialogs from WPF, but here’s where it gets crazy: WPF handles fonts and colors so completely differently that interfacing with them is next to impossible. Consider the basic task of displaying the Font dialog in .NETpad so that the user can change the font. I’ve figured out how to map the WinForms Font object to the various WPF font objects, but in one direction only: So I can change the font in the app’s textbox, but I can’t (yet?) get that Font dialog to display the font that the textbox is currently using. It’s madness.

Of course, WPF wasn’t designed to create classic Windows desktop applications, it was designed to create what was, in 2003-to-2007 a new class of content-based applications that would dynamically display data in visually-pleasing ways. When that went nowhere fast, Microsoft took the XAML technologies from WPF and evolved them for a new generation of sandboxed mobile apps that are now called Store apps (but were originally called Metro app); UWP is the latest version of this effort.

If you followed along with the development of .NETpad, you know that I have created many dozens of side projects along the way. Some were designed to test individual features that later did or did not get added to .NETpad. And some were just dead-ends. But I haven’t really discussed two of the biggest side projects, both of which are still ongoing.

The first is a direct port of .NETpad to C#. This means that it’s still based on Windows Forms and the .NET Framework, and that I’ve hand-written the code in C#, using my VB original as a guide. As of today, that project is nearly complete: The only major things I’ve not yet added are the printing and Find/Replace bits. I don’t see going through a series of articles describing how to create this one from scratch, but I’ll likely write up what I’ve learned about C#, since the language differences with VB are, to me at least, interesting.

The second is a WPF version of .NETpad, which is also written with C# and to the .NET Framework. I started and restarted this one several times, but it’s finally in a good place. The only question is whether I use the WinForms dialogs, which is problematic (see above) or create my own dialogs in WPF. That type of thing is terrible to do in WinForms, but it’s actually not a bad experience in WPF, and I think that might be the better approach, since it will keep the app a “pure” WPF app, such as that is. I’m not sure how that one will be documented, but if it is a series of articles, it will be a short one focusing on the key differences. I see this as an experiment for a future WPF project, one in which I use something familiar (.NETpad) to learn something unfamiliar (XAML/WPF).

(Humorously, I also started recreating .NETpad in classic VB 6 for the heck of it. I think that it would be sort-of possible to make it work, but it’s obviously a waste of time, and I gave up on it.)

Anyway, I still have some fit and finish work to do on the original .NETpad, and I may still add more features. But I have this other stuff floating around that I need to figure out. And beyond all that, I need to think about what’s next. And that’s where I’d like your help. I feel like the next major new project should be C# and WPF (and possibly .NET Core-based), and that it should be true to that environment (as .NETpad was true to VB/WinForms/.NET Framework). It can be basic, like a weather app or whatever. Maybe a basic to-do app. Something like that.

But let me know what you think should be next.