What’s new in Windows Forms in .NET 6.0

Igor Velikorossov

We continue to support and innovate in Windows Forms runtime. Let’s recap what we’ve done in .NET 6.0.

Accessibility improvements and fixes

Accessibility improvements, What’s new in Windows Forms in .NET 6.0

Making Windows Forms applications more accessible to more users is one of the big goals for the team. Building on the momentum we gained in .NET 5.0 timeframe in this release we delivered further improvements, including but not limited to the following:

  • Improved support for assistive technology when using Windows Forms apps. UIA providers enable tools like Narrator and others to interact with the elements of an application. UIA is also often used to create test automation to drive apps. We have now added UIA providers support for the following controls:

    • CheckedListBox
    • LinkLabel
    • Panel
    • ScrollBar
    • TabControl
    • TrackBar
  • Improved Narrator announcements in DataGridView, ErrorProvider and ListView column header controls.
  • Keyboard tooltips for the TabControl’s TabPage and the TreeView’s TreeNode controls.
  • ScrollItem Control Pattern support for ComboBoxItemAccessibleObject.
  • Corrected control types for better support of Text Control Patterns.
  • ExpandCollapse Control Pattern support for the DateTimePicker control.
  • Invoke Control Pattern support for the UpDownButtons component in DomainUpDown and NumericUpDown controls.
  • Improved color contrast in the following controls:
    • CheckedListBox
    • DataGridView
    • Label
    • PropertyGridView
    • ToolStripButton

 

Application bootstrap

In .NET Core 3.0 we started to modernize and rejuvenate Windows Forms. As part of that initiative we changed the default font to Segoe UI, 9f (dotnet/winforms#656), and quickly learned that a great number of things depended on this default font metrics. For example, the designer was no longer a true WYSIWYG, as Visual Studio process is run under .NET Framework 4.7.2 and uses the old default font (Microsoft Sans Serif, 8.25f), and .NET application at runtime uses the new font. This change also made it harder for some customers to migrate their large applications with pixel-perfect layouts. Whilst we had provided migration strategies, applying those across hundreds of forms and controls could be a significant undertaking.

To make it easier to migrate those pixel-perfect apps we introduced a new API (for more details refer to the Application-wide default font post):

void Application.SetDefaultFont(Font font)

However, this API wasn’t sufficient to address the designer’s ability to render forms and controls with the same new font. At the same time, with our sister teams heavily pushing for little code/low ceremony application templates, our Program.cs and its Main() method started looking very dated, and we decided to follow the general .NET trend and trim the boilerplate. Please welcome the new Windows Forms application bootstrap:

class Program
{
    [STAThread]
    static void Main()
    {
        ApplicationConfiguration.Initialize();
        Application.Run(new Form1());
    }
}

ApplicationConfiguration.Initialize() is a source generated API that behind the scenes emits the following calls:

Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.SetDefaultFont(new Font(...));
Application.SetHighDpiMode(HighDpiMode.SystemAware);

The parameters of these calls are configurable via MSBuild properties in csproj or props files. The Windows Forms designer in Visual Studio 2022 is also aware of these properties (for now it only reads the default font), and can show you your application (C#, .NET 6.0 and above) as it would look at runtime:

Application bootstrap. What’s new in Windows Forms in .NET 6.0

(We know, the form in the designer still has that Windows 7 look, We’re working on it…)

Please note that Visual Basic handles these application-wide default values differently. In .NET 6.0 Visual Basic introduces a new application event ApplyApplicationDefaults which allows you to define application-wide settings (e.g., HighDpiMode or the default font) in the typical Visual Basic way. The designer support for the default font configured via MSBuild properties is also coming in the near future. For more details head over to the dedicated Visual Basic blog post discussing what’s new in Visual Basic.

 

Template updates

As mentioned above we have updated our C# templates in line with related changes in .NET workloads, Windows Forms templates for C# have been updated to support global using directives, file-scoped namespaces, and nullable reference types. Because a typical Windows Forms app requires a STAThread attribute and consist of multiple types split across multiple files (e.g., Form1.cs and Form1.Designer.cs) the top-level statements are notably absent from the Windows Forms templates. However, the updated templates do include the application bootstrap code.

Templates. What’s new in Windows Forms in .NET 6.0

 

More runtime designers

We have completed porting missing designers and designer-related infrastructure that enable building a general-purpose designer (e.g., a report designer). For more details refer to our earlier announcement.

Tiny Designer by Paolo Foti

If you think we missed a designer that your application depends on, please let us know at our GitHub repository.

 

High DPI and scaling fixes

We’ve been working through the high DPI space with the aim to get Windows Forms applications to correctly support PerMonitorV2 mode out of the box. It is a challenging undertaking, and sadly we couldn’t achieve as much as we’d hoped. Still in this release we made some progress, and we now can:

  • Create controls in the same DPI awarenes as the application
  • Correctly scale ContainerControls and MDI child windows in PerMonitorV2 mode in most scenarios. There are still few specific scenarios (e.g., anchoring) and controls (e.g., MonthCalendar) where the experience remains subpar. Scaling, What’s new in Windows Forms in .NET 6.0

 

Other notable changes

  • New overloads for Control.Invoke() and Control.BeginInvoke() methods that take Action and Func<T> and allow writing more modern and concise code.
  • New Control.IsAncestorSiteInDesignMode API is complimentary to Component.DesignMode, and indicates if one of the ancestors of this control is sited, and that site in design mode. A dedicated blog post exploring this API is coming later, so stay tuned.
  • Windows 11 style default tooltip behavior makes the tooltip remain open when mouse hovers over it, and not disappear automatically. The tooltip can be dismissed by CONTROL or ESCAPE keys.

 

Community contributions

We’d like to call out a few community contributions:

 

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.

Happy coding!

30 comments

Discussion is closed. Login to edit/delete existing comments.

  • Brandon Williams 0

    Bravo!

  • RedShark 0

    “We know, the form in the designer still has that Windows XP look, We’re working on it…” – did you mean Windows 7? cause Windows XP never had that look…
    Also, please add native dark mode to WinForms applications!

    • Igor VelikorossovMicrosoft employee 0

      Thank you, fixed. It’s been awhile since I used either.

      The team is acutely aware of the desire for the theming of Win32 apps, unfortunately it has dependencies on Windows API, and there are challenges resolving this. We’re actively engaged with our partners in Windows but don’t have an ETA at this time.

      • Reilly Wood 0

        unfortunately it has dependencies on Windows API, and there are challenges resolving this

        To elaborate, I believe the main challenge is that Windows still does not have a documented way to check whether the system is in light or dark mode. Please correct me if I’m wrong about that.

        • Igor VelikorossovMicrosoft employee 0

          Yes, this is one of the issues.

  • Daniel Smith 0

    Congrats to everyone on the WinForms team for a great release! The per monitor high DPI work sounds especially challenging, and it’s totally understandable that it’ll take time to cover all the nuances.

    Is there a roadmap ahead for .NET 7? The top feature for me would be to re-enable support for the Data Sources window. Being able to drag and drop classes from that window, and have the controls automatically created and data bound is a huge time saver.

    • Igor VelikorossovMicrosoft employee 0

      Thank you.

      Yes, there is a roadmap, and we plan to make it public in the near future. In the nutshell making high DPI work out of the box is very high on our priority list.
      You can keep an eye on the .NET 7.0 milestone (which is a “catch all” at the moment, but we keep reviewing it).

    • Merrie McGawMicrosoft employee 0

      I totally echo what Igor says here, and I’d also encourage you to keep an eye out for a similar post talking about WinForms Designer in VS2022. We’ve added some features around data that I think you might like 😁. Our first VS related blogpost should be published sometime next month.

    • schbaem 0

      I don’t know, it would have been nice to have the high DPI fixes in the long term release. It was clear at the start of the .NET6 development cycle that HDPI support in winforms is a desaster. Once you have monitors with different DPIs each, the default framework windows/forms/controls start to look and behave like total junk.

  • John King 0

    it WPF dead ? there no news from .net 5/6 side

    • Muhammad Miftah 0

      The lack of .NET 6 specific news for WPF does not mean it is dead; alot of the hard work that went into porting WPF to .NET Core happened back during the .NET Core 3.* release. When Microsoft ported WPF+WinForms to .NET Core, they probably had to leave a lot out for WinForms initially, and they’re now finally getting around to it this release.

      Microsoft did recently open source the unit testing suite for WPF: https://github.com/dotnet/wpf-test

      • Fabien Geraud 0

        alot of the hard work that went into porting WPF to .NET Core

        Done on .Net core 3. There was no work on this on .Net core 5 or .Net 6. You can look the commit on github. There is no commit on this.

        Microsoft did recently open source the unit testing suite for WPF

        Officially that on what they work on for the last 3 years (Again you can read all the commit done the last three years. It may seems like a big job but there is less thant one real commit a month so it will be quick). No work on anythinks else. Except in visual studio with the new designer and some improvement on intellisense for xaml.

    • Max Mustermueller 0

      Yes it is. Look at the new roadmap for 2022. There is no new stuff coming, no improvements. And meanwhile ALL community PRs which adds new code are left
      completely unreviewed. On some of them the authors have just closed the PR because after more than half a year there was no activity from the “WPF team”.

    • Huo Yaoyuan 0

      As I inferred from some talks, there is a shared team for xaml UI. There are plenty of work done for WinUI this year, and many things are still on backlog. I’m afraid there’s no enough people to work on WPF.

  • Guido Geurts 0

    It would be nice if they would fix bugs first, before adding new stuff.
    Visual Inheritance is still a nightmare in the designer, please finally fix that.

  • Cristian Luis Teixeira 0

    good news
    Special thanks to Paul M Cohen @ paul 1956

  • ke zhou 0

    Is it possible that WinForm supports Linux?

    • Igor VelikorossovMicrosoft employee 0

      There are no official plans to support other OS than Windows.

      • Adam Byron 0

        Windows 11 supports

    • Maximilien Noal 0

      Use AvalonaUI, it’s very good.

  • sergio 0

    Form Designer in release VS 2022 works much better, it was way too slow I checked it last time some months ago. Thank you.

    Is there any special reason why Toolbox shows Framework custom controls disabled for Net 6.0 project? My Net 6.0 app uses some my controls from Net Framework 4.5 dll. When added to the form by the code, the controls seem work just fine, both in design- and run-time. The only problem is that Toolbox shows them grayed out. I see no clear reason for that: once I can manage the controls on the form (copy/paste them, change properties, delete) why can’t they be dragged from Toolbox?

  • Rob Ainscough 0

    Thank you for the update/blog, but still no mention of DirectX 11 or 12 or (13 for 2022) native support in .NET 6. I still don’t understand why Microsoft are avoiding DirectX in .NET? From a competitive standpoint, we have Vulkan for Java via LWJGL – Khronos.

    MDX, XNA, SharpDX, SlimDX are all dead in the water

    DirectX still seems to be exclusive to C++ (not C++.NET) … I don’t see how keeping DirectX restricted to a very a narrow development base as being good for Microsoft?

    Cheers, Rob.

    • Andrey Kurdyumov 0

      You can take a look at TerraFX. https://github.com/terrafx/terrafx , That library also has Vulkan if you want it.

  • Davide 0

    Hello, I have an application written with .net framework 4.8, for many factors I can’t make it compatible with devices that have high DPI. Now I wanted to rewrite everything with visual studio 2022 using .net 6. (I don’t digest UWP and WPF XD) Do you have any advice to give in this regard? Using VS 2022 .Net6 I have seen that in the winforms design you have removed the dpi scaling warning, I suppose that this problem has also been solved, and therefore we will no longer have problems developing using devices with high DPI (for example my notebook) I gladly accept any of your suggestions.

    • Igor VelikorossovMicrosoft employee 0

      Unfortunately for .NET applications we had to remove the goldbar from VS because restarting with /noscale made the new .NET designer literally unusable – processes with different DPI settings don’t play nicely. We are exploring alternatives, in mean time the recommendation is to design at 100% scale factor.
      (Please note the goldbar is still there for the .NET Framework designer.)

      • Davide 0

        I will follow your advice to keep designing with 100% scale. Igor, do your best with your team. Know that you have millions of developers all over the world who have been waiting too long for a solution to solve this problem of high DPI, which as time passes becomes more and more burdensome, I would say from now on I would also define it as serious. It is a problem to distribute applications, and it is also a problem to have to scale to 100% for someone like me who has a notebook panel that has high DPI, by doing so you make in a certain sense almost nil the work you do to improve the experience of ‘ use of Visual Studio having to reduce everything to 100%. To date, however, it is unacceptable to have to force a developer to switch to UWP. The ideal would be to be able to have a render equal to UWP, without us developers having to worry about resizing. In the meantime I leave my application with Netframework 4.8, at this point I find it senseless to have to waste time migrating my application to .net 5/6. We count on your work. Thanks Igor

Feedback usabilla icon