Microsoft’s oldest .NET desktop framework, Windows Forms, has been improved for .NET 6, though full support for high resolution displays is “a challenging undertaking,” according to software engineer Igor Velikorossov.
The first release of Windows Forms was in February 2002, when it was positioned as the successor to Visual Basic 6.0 (1998) as a rapid application development framework for Windows desktop applications. There was huge friction in that transition, but it was nevertheless popular and easy to use. Underneath Windows Forms lies the Win32 API and the GDI+ graphics API.
In late 2006, Microsoft introduced Windows Vista and along with it a new .NET desktop framework called Windows Presentation Foundation (WPF). Unlike Windows Forms, it used DirectX to render graphics, enabling richer designs with hardware accelerated performance.
WPF was also designed to scale nicely irrespective of the display resolution and Windows display settings, thanks to use of layout managers for positioning user interface elements.
Why is Microsoft still investing in Windows Forms, the oldest .NET desktop framework, when it has been replaced several times, first by WPF, then by Windows 8 with its Windows Runtime APIs, then by UWP (Universal Windows Platform), and most recently by WinUI 3 (also known as Project Reunion)? The answer is simply the popularity of the framework and the number of legacy business applications that use it. Third-party component vendors also gave good support to the platform.
It seems that despite the technical superiority of WPF, many business developers find Windows Forms easier, perhaps because of its apparently simple form designer where a button or checkbox stays where it is placed, at least until users with different display settings complain about overlapping text or chopped-off characters.
Windows Forms is only for Windows and not much was done to it for some years, especially as it was for .NET Framework and most development effort was going into the open source .NET Core. That changed when .NET Core 3.0 was released, with support for both Windows Forms and WPF. At this point both frameworks became open source, though this was a fork and Velikorossov’s post about what’s new in Windows Forms concerns the .NET 6.0 version, not the .NET Framework one.
Migration of an existing application is not straightforward and may be impossible without major surgery.
Some features of .NET Framework, include Application Domains, .NET Remoting, Windows Workflow Foundation, and Windows Communication Foundation (WCF), with WCF being the most problematic.
Remote communication using SOAP (an XML remoting standard) and WCF was widely used, often with ASP.NET on the web server and a Windows Forms client.
Despite these issues, Microsoft has added features including accessibility improvements – such as better screen narrator support and user interface automation – updated templates to support the new .NET 6.0 global using directive, and new runtime designers. “In .NET Core 3.0 we started to modernize and rejuvenate Windows Forms,” said Velikorossov.
The biggest challenge remains scaling and high DPI (dots per inch) displays. The original scaling method for Windows Forms was based on the default system font, on whose size all the autoscaling of a form depended. It was not a good system. There were rounding errors, issues with user controls and with form inheritance, and “forms and their child controls could only be concurrently designed by multiple developers if their machine resolutions were the same,” say the docs.
There were tweaks, but high DPI support did not arrive until .NET Framework 4.7 and only worked on Windows 10 Creators Update and later. When the .NET Core version came along, Velikorossov describes how the team changed the default font and “quickly learned that a great number of things depended on this default font metrics.”
The aim of full support for per-monitor V2 DPI awareness remains, meaning that applications are never bitmap scaled by Windows (causing fuzzy fonts) but are notified when DPI changes, maybe because of a setting change or a window being dragged to another display. “It is a challenging undertaking, and sadly we couldn’t achieve as much as we’d hoped,” said Velikorossov, but there are improvements with correct scaling of container controls and MDI child windows “in most scenarios.”
There are also community contributions to Windows Forms for .NET 6.0 including MessageBox, used for quick dialogs requiring user confirmation or input, optionally getting two new buttons: Try Again, and Continue.
Developers reacted to Velikorossov’s post with some requests. “Please add native dark mode,” was one, though apparently a challenge here is that “Windows still does not have a documented way to check whether the system is in light or dark mode.” Another commented gratefully that the “Form Designer in release VS 2022 works much better, it was way too slow.”
When the .NET Foundation conducted a developer survey earlier this year, WPF and Windows Forms came out as more widely used than Microsoft’s more recent efforts.
It is not a good choice for a GUI application today, being Windows-only and a weak option even on Windows, yet legacy combined with its initial ease of use means it will be around for many years to come, something developers are less sure about with some other .NET technologies. ®