What’s new in Windows Forms runtime in .NET 5.0
Since Windows Forms was open sourced in late 2018, and ported to .NET Core, both the team and our external contributors have been busy fixing old bugs and adding new features. In this post we are going to talk about what’s new in Windows Forms runtime in .NET 5.0.
Windows controls additions and enhancements
Perhaps the most exciting thing about Windows Forms today is the vibrant and engaged community we have on GitHub. Many of the new features and enhancements have been either suggested by, or even fully implemented by our community members. In the .NET 5.0 timeframe we have accepted and merged over 900 pull-request with over 70% of those PRs coming from our community. Massive shoutouts to @hughbe, @gpetrou, @weltkante, @kpreisser and many, many others who helped us improve Windows Forms runtime.
Here are a few examples of the contributions we have received from the community.
New TaskDialog control
Contributed by @kpreisser | Documentation | Task dialog sample
A task dialog is a dialog box that can be used to display information and receive simple input from the user, but has more features than a message box. Like a message box, it’s formatted by the operating system according to parameters you set.
Contributed by @hughbe and @lonitra | Documentation
ListView control is quite familiar to the Windows Forms developers, yet it was lacking API for an easy access to several features that were added in Windows Vista, such as collapsible groups, groups tasks, subtitles, and footers.
In .NET 5.0 we bridged the API gap, and now the Windows Forms
ListView is much closer to parity with the native Win32 control.
The new API include:
- ListView group collapse/expand
- ListView group footers
- ListView group subtitles
- ListView group tasks
- ListView group title image
Contributed by @jnm2 | Documentation
FileDialog has received a new API:
FileDialog.ClientGuid. The Windows file dialog enables a calling application to associate a GUID with a dialog’s persisted state. A dialog’s state can include factors such as the last visited folder and the position and size of the dialog. Typically, this state is persisted based on the name of the executable file. By specifying a GUID, an application can have different persisted states for different versions of the dialog within the same application (for example, an import dialog and an open dialog).
Windows Forms has always been known as a managed wrapper around the Win32 API set. As such, Windows Forms has always depended heavily on an interop layer to communicate with the unmanaged Windows components. The top priority from the early days of .NET Core has been the optimising of our interop layer, making structs blittable, explicitly opting for more efficient “W”-functions, and using “unsafe” code where possible. All these changes are what we call “peanut butter changes”, in a sense that each of these are tiny and hardly observable, but over a lifetime of an application these changes add up to a substantial performance gains.
In .NET 5.0 we’ve lifted the bar higher and optimised several painting paths. Historically Windows Forms relied on GDI+ (and some GDI) for rendering operations. Whilst GDI+ is easier to use than GDI because it abstracts the device context (a structure with information about a particular display device, such as a monitor or a printer) via the
Graphics object, it’s also slow due to the additional overhead. In a number of situations where we deal with solid colours and brushes, we have opted to use GDI.
We have also extended a number rendering-related APIs (e.g.
IDeviceContext interface, which whilst may not be available to Windows Forms developers directly, allow us to bypass the GDI+
Graphics object, and thus reduce allocations and gain speed.
These optimisations have shown a significant reduction in memory consumptions in redraw paths, in some cases saving x10 in memory allocations).
For a more technical dive you can watch the API Review segment, or watch the .NET Community Standup segment where Jeremy Kuhne talks about these optimisations.
You can grab the test project here: https://github.com/JeremyKuhne/RedrawPerformance, and verify the results yourself, just like one of our users – Jeremy Sinclair:
Last but not least, we have extended
TextRenderer API to accept
ReadOnlySpan<char> overloads, because drawing and measuring text is a pretty common activity. This will allow significantly more efficient text rendering when new string allocations can be avoided (slicing other input, building off a stack-based character array, etc.).
Accessibility improvements and fixes
For the past several years the team has been updating the 20-year-old Windows Forms SDK to meet today’s accessibility requirements and compliance.
In .NET 5.0 we have delivered many improvements, including but not limited to the following:
- UI Automation support for a number of controls including:
- LegacyIAccessible Control Pattern support enabling clients to better interact with UI controls, and allowing developers to set custom
AccessibleRoleproperties for their controls.
- Text and TextRange Control Patterns support enabling clients to retrieve textual content, text attributes, and embedded objects from text-based controls.
We have also fixed several issues which impacted the UX under certain accessibility tools. For example, we have reworked the accessibility implementations in the way that accessing an
AccessibleObject will no longer cause a premature control’s
Handle creation, which in turn ensures more predictable control behaviors and avoids unexpected surprises in the UI.
We also improved and corrected behaviours in several controls (such as
MonthCalendar) that could prevent accessibility tools from correctly navigate the UI or, in severe cases, crash applications.
Visual Basic support
Visual Basic, along with its Application Framework, is supported in .NET 5 and Visual Studio 16.8! Visual Studio 16.8 includes the Windows Forms Designer, so Visual Basic is ready for you to migrate existing applications or create new applications.
For more information refer to Visual Basic WinForms Apps in .NET 5 and Visual Studio 16.8 post.
Kudos to @paul1956 for helping us with Visual Basic related issues.
Whilst we intend to maintain backward compatibility with .NET Framework and .NET Core as much as possible, it is not always prudent. You can find the list of breaking changes here:
For the list of known issues please refer to .NET 5.0 Known Issues document.
We are aware that the current high DPI support is far from perfect, and this is something we are planning to improve in the .NET 6.0 timeframe. There are many aspects to what “high DPI support” means, so we would love to learn more about what it means to you. If you have a specific concern that you’d like us to address, please leave a comment below or file an issue directly in dotnet/winforms.
We plan to continue with “peanut butter” optimisations, accessibility improvements, nullable reference types annotations, and general code improvements.
Reporting bugs and suggesting features
If you have any comments, suggestions or faced some issues, please let us know! Submit Visual Studio and Designer related issues via Visual Studio Feedback (look for a button in the top right corner in Visual Studio), and Windows Forms runtime related issues at our GitHub repository.
We also consider API proposals that further enrich Windows Forms SDK and make it easier to build Windows applications (like the task dialog). And if you champion a proposal – there is a high chance that you will see it in the Windows Forms SDK.
You can also become a contributor to the Windows Forms code base! Our repository has items marked “up for grabs” and approved ready-for-development API, we would really appreciate your help implementing them!
Meanwhile, what’s new in WPF? Nothing. Not even a one liner commit got even reviewed over a year. Thanks for improving Winforms. Only shows that WPF team is terrible and you cannot say its because of WinUI or MAUI. Winforms team does an excellent job on working together with the community. It’s great to see all that new stuff… and also it’s extremely frustrating that most of it won’t come to WPF. Taskdialog? Well yeah, but no. Even the improved folder dialog that got merged in .NET 3.0 era… you won’t find anything like that in WPF.
I don’t know. This blog post makes me happy and sad all together.
Completely agree with this comment. Nice to see the progress for WinForms. But I would like to see the same commitment for the WPF repo. It’s not like the community does want to bring new stuff to WPF, but unfortunately it’s the repo owners, who are the limiting factor here. 🙁
Actually, you can, because it is the same team which owns both. WPF is hardly under control of the .NET team now.
At the rate we’re going, someone will fork WPF and fix the bugs and bottlenecks, and it won’t be under any political influence of Microsoft or the .NET Foundation, because they’ve only proven themselves as ineffective and unwilling. The community is ultimately not going to let the #1 UI framework of all time rot on the vine just to make Google and Apple happy. God forbid it.
Why doesn’t .net5 or .netcore support Microsoft report viewer.
The priority of MS is PowerBI.
What an enshamed called priority..
If the reports are hosted on SSRS, you could always migrate to using a web viewer control. Not a direct replacement, but it at least gets you up-and-running.
Many thanks to you Igor. Nice article!
Looking forward for DPI overhaul…
P.s. the main thing that prevent fully using of .net5 and winforms is new designer. It’s still have critical bugs, no documentation and clarity about user controls support 🙁
Are you freaking kidding us ? While Apple prepare everything to move ARM architecture, you still spend your employee resource to maintain Win32 ?
WHERE ARE UWP UPDATE ?
It’s been a while since i worked on a WinForms App, but this kind of news stills excite me.
Btw, what’s the timeline on the new WinForms designer?
thank you so much
And what for WPF ? 😮
Why spending time on WinForm when WPF is not improve at all ?!
Is the wpf repo dead?
Thank you for continuing to be active proponents of the WPF platform. The WPF team has been challenged with extremely limited dev resourcing for several months. With the limited resources on hand, we have been heads-down on getting support for .NET5 released and now are working on ARM64 support. However, the good news is that our team has now been approved for more new developer recruits to be on-boarded by the end of Jan/beginning of Feb 2021. Once they are onboarded, one of the first tasks we have lined up is open sourcing of our Test Infrastructure which in turn will get us going on more regular PR approvals and check-ins. In the meantime, please continue to send us your PRs and file Issues -all of which only aid in improving the platform for the community .We look forward to closer and active collaboration with the community in the New Year.
Thank you. I hope there are some good news about WPF and MAUI, WinUI 3.0 on https://focus.dotnetconf.net/
we’ve just moved our site (Termeh Travel) from net core 3 to net core 5 and the performance improvement is really something