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 ...