News

In VS 2022, WinForms Designer Still Chasing Parity with .NET Framework Version

• By David Ramel
• 01/13/2022

Microsoft provided an update on its years-long effort to bring the new Windows Forms designer up to speed with the old .NET Framework version.

Duplicating the .NET Framework WinForms designer on .NET Core (which became just .NET 5, .NET 6, etc.) proved to be a thorny problem for the dev team, which mentioned it was a "huge technical challenge" way back in 2019.

That challenge resulted from having to move the designer out of the devenv.exe process because the "Core" version couldn't run in the same process as the Visual Studio environment, like it could in .NET Framework.

"For developers the .NET Core Windows Forms Designer (when we will release the GA version) will look and feel the same as the .NET Framework Windows Forms Designer," said Olia Gavrysh, program manager, .NET, back in 2019. "But for us it is a huge technical challenge to bring the designer to .NET Core because it requires the design surface that hosts the live .NET Core form to run outside the Visual Studio process. That means we need to re-architect the way the designer surface 'communicates' with Visual Studio."

Now, more than two years later, the Herculean effort is nearing parity, but it's not quite there yet, missing the goal Microsoft had planned for the Nov. 8, 2021, release of Visual Studio 2022.

"While we aimed at complete parity between the OOP designer and the .NET Framework designer for the release of Visual Studio 2022, there are still a few issues on our backlog," said the dev team's Klaus Loeffelmann in a Jan. 13 blog post.

The areas that need work were listed as:

• The Tab Order interaction has been implemented and is currently tested. This feature will be available in Visual Studio 17.1 Preview 3. Apart from the Tab Order functionality you already found in the .NET Framework Designer, we have planned to extend the Tab Order Interaction, which will make it easier to reorder especially in large forms or parts of a large form.
• The Component Designer has not been finalized yet, and we're actively working on that. The usage of Components, however, is fully supported, and the Component Tray has parity with the .NET Framework Designer. Note though, that not all components which were available by default in the ToolBox in .NET Framework are supported in the OOP Designer. We have decided not to support those components in the OOP Designer, which are only available through .NET Platform Extensions (see Windows Compatibility Pack). You can, of course, use those components directly in code in .NET, should you still need them.
• The Typed DataSet Designer is not part of the OOP Designer. The same is true for type editors which lead directly to the SQL Query Editor in .NET Framework (like the DataSet component editor). Typed DataSets need the so-called Data Source Provider Service, which does not belong to WinForms. While we have modernized the support for Object Data Sources and encourage Developers to use this along with more modern ORMs like EFCore, the OOP Designer can handle typed DataSets on existing forms, which have been ported from .NET Framework projects, in a limited scope.

That said, most of the significant improvements at important levels have been achieved, Loeffelmann said, listing these:

• Performance: Starting with Visual Studio 2019 v16.10, the performance of the OOP designer has been improved considerably. We've worked on reducing project load times and improved the experience of interacting with controls on the design surface, like selecting and moving controls.
• Databinding Support: WinForms in Visual Studio 2022 brings a streamlined approach for managing Data Sources in the OOP designer with the primary focus on Object Data Sources. This new approach is unique to the OOP designer and .NET based applications.
• WinForms Designer Extensibility SDK: Due to the conceptional differences between the OOP designer and the .NET Framework designer, providers for 3rd party controls for .NET will need to use a dedicated WinForms Designer SDK to develop custom Control Designers which run in the context of the OOP designer. We have published a pre-release version of the SDK last month as a NuGet package, and you can download it here. We will be updating this package to make it provide IntelliSense in the first quarter of 2022. There will also be a dedicated blog post about the SDK in the coming weeks.

Loeffelmann's huge post delves deep into the nitty-gritty details of the WinForms designer and how it works for those who want a complete of an understanding of the technical aspects, but he boiled down the dense information into three key takeaways:

• We have taken the .NET WinForms Designer out of proc. While Visual Studio 2022 is 64-Bit .NET Framework only, the new Designer's server process runs in the respective bitness of the project and as a .NET process. That, however, comes with a couple of breaking changes, mostly around the authoring of Control Designers.
• Databinding is focused around Object Data Sources. While legacy support for maintaining Typed DataSet-based data layers is currently supported in a limited way, for .NET we recommend using modern ORMs like EntityFramework or even better: EFCore. Use the DesignBindingPicker and the new Databinding Dialog to set up Object Data Sources.
• Control library authors, who need more Design Time Support for their controls than custom type editors, need the WinForms Designer Extensibility SDK. Framework control designers no longer work without adjusting them for the new OOP architecture of the .NET WinForms Designer.

"Let us know what topics you would like hear from us around the WinForms Designer -- the new Object Data Source functionality in the OOP Designer and the WinForms Designer SDK are the topics already in the making and on top of our list," Loeffelmann said.