.NET 5 Breaking Changes for WPF/Windows Forms

Write for InfoQ

The final topic in our .NET 5 Breaking Changes series is WPF and Windows Forms. These desktop technologies were unavailable before .NET Core 3.0, as earlier versions of .NET Core focused on web-based applications via ASP.NET Core.

Windows Forms, unofficially known as WinForms, was one of the original application frameworks when .NET was first released in 2002. (The other frameworks were WebForms, console, and Windows Services.) WinForms was heavily influenced by Visual Basic, and like VB it acts as a thin wrapper around native Windows controls. This offers really good performance in the default case, but is fairly limited on customizations. Generally speaking, developers would allow the OS to handle aspects such as styling.

The first major change to WinForms came with .NET 2.0 in 2005. This introduced replacements for a variety of user controls Microsoft felt were insufficient, including the basic data grid. Since then, the technology has been considered “complete.” The only notable change has been occasional updates to support higher DPI monitors. Even long outstanding bugs were usually ignored, much to the annoyance of developers who continue to use WinForms for new development.

Windows Presentation Foundation (WPF) was Microsoft’s first attempt at creating a fully customizable GUI framework. Though released only four years after WinForms, it took a while to be generally accepted because the design patterns and concepts were more complex. Performance could also be a problem. While there are techniques such as virtualization that can make WPF significantly faster than WinForms for large data sets, they require a deeper knowledge to use correctly. Furthermore, many developers felt custom styling was required because the default styles were “ugly”.

The two key ‘features’ of WPF that had a lasting impact were the use of XAML for UI layout and the MVVM pattern for data-binding. These were carried over into other initiatives such as Silverlight and Universal Windows Platform.

Like WinForms, WPF has been considered to be “complete” for many years. It didn’t even pick up XAML-2009 support, even after the XAML specification was released in 2012. In response, projects such as Avalonia have sought to improve upon WPF flaws. An example of this would be allowing events to be bound directly to a method on a model or view-model.

New SDK

With .NET Core 3.x, WPF and WinForms needed a custom SDK called Microsoft.NET.Sdk.WindowsDesktop. With .NET 5, they now use Microsoft.NET.Sdk, just like any other .NET 5 project. However, the target framework is now net5.0-windows instead of just net5.0.

Console Output Suppressed

While the vast majority of WPF and WinForms applications don’t show a console window, that’s not actually required; it is just the default. If you need a place to spill additional diagnostic information, you can set the OutputType to Exe instead of WinExe.

In .NET 5, the OutputType setting will be ignored unless you also set DisableWinExeOutputInference to true.

Improved Error Handling

Even fixes to error handling can result in breaking changes. In Windows Forms for .NET Core 3, a lot of the validation code simply didn’t exist. Which means if you passed in an invalid argument it could throw a NullReferenceException or just behave in an indeterminate fashion.

With .NET 5, the appropriate ArgumentException, ArgumentNullException, or ArgumentOutOfRangeException will be thrown. If a required property is null, rather than an argument, then an InvalidOperationException will be used instead.

For more information on how write code that properly uses exceptions, see Designing with Exceptions in .NET.

Removed Status Bar Controls

The reason we covered the history of WinForms above was to explain what’s happening with the status bar controls. One of the controls replaced in .NET Framework 2 was the humble StatusBar . The .NET 2 equivalent is the StatusStrip , which for all intents and purposes does the same job.

Microsoft didn’t explain why it needed to be removed, so presumably the maintenance cost was simply too high for a control that most people don’t even know exists. StatusBar hasn’t been visible in the designer toolbox for a very long time and has been completely removed as of .NET 5.

Complete Series

• .NET 5 Breaking Changes to the Base Class Library
• .NET 5 Breaking Changes: Historic Technologies
• .NET 5 Breaking Changes for ASP.NET Core

Related Topics:

• Development
• .NET
• .NET 5
• WinForms
• WPF

We protect your privacy.