In VS 2022, WinForms Designer still pursues parity with .NET Framework version
Microsoft has provided an update on its years of effort to upgrade the new Windows Forms designer to the older version of .NET Framework.
Duplicating the .NET Framework WinForms designer on .NET Core (which became just .NET 5, .NET 6, etc.) proved to be a thorny issue for the development team, who mentioned that it is was a “huge technical challenge”. 2019.
This challenge resulted from having to move the designer out of the devenv.exe because the “Core” version could not run in the same process as the Visual Studio environment, as it could in .NET Framework.
“For developers, the .NET Core Windows Forms Designer (when we release the GA version) will look the same as the .NET Framework Windows Forms Designer,” said Olia Gavrysh, Program Manager, .NET, in 2019 But for us, it’s 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 of the Visual Studio process. the design surface “communicates” with Visual Studio.”
Now, more than two years later, the Herculean effort is approaching parity, but it’s not quite there yet, missing the target Microsoft had set for the release of Visual Studio 2022 on November 8, 2021.
“Although we have aimed for full parity between the OOP designer and the .NET Framework designer for the release of Visual Studio 2022, there are still some issues in our backlog,” said Klaus Loeffelmann of the development team. in a January 13 blog post. Publish.
Areas requiring work have been listed as follows:
- the Tab order interaction has been implemented and is currently being tested. This feature will be available in Visual Studio 17.1 Preview 3. In addition to the tab order feature you already found in the .NET Framework designer, we plan to extend the tab order interaction, which will make it easier rearranging, especially in large forms or parts of a large form.
- the Component designer has not yet been finalized and we are actively working on it. Working with components, however, is fully supported, and the component bar is on par with the .NET Framework designer. Note, however, that not all components that were available by default in the Toolbox in the .NET Framework are supported in the OOP designer. We have decided not to support these components in the OOP designer, which are only available through .NET platform extensions (see Windows Compatibility Pack). You can, of course, use these components directly in .NET code, if you still need them.
- the Typed DataSet Designer is not part of the OOP designer. The same goes for type editors that lead directly to the SQL Query Editor in .NET Framework (like the DataSet Component Editor). Typed DataSets need something called Data Source Provider Service, which is not owned by WinForms. Although we have modernized the support for Object Data Sources and encourage developers to use it 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 significant improvements at important levels have been achieved, Loeffelmann said, listing them:
- Performance: Starting with Visual Studio 2019 v16.10, the performance of the OOP designer has been significantly improved. We worked on reducing project load times and improving the experience of interacting with controls on the design surface, such as selecting and moving controls.
- Data binding support: WinForms in Visual Studio 2022 brings a simplified approach for managing data sources in the OOP designer with the primary focus on object data sources. This new approach is unique to OOP Designer and .NET-based applications.
- WinForms Designer Extensibility SDK: Due to design differences between the OOP designer and the .NET Framework designer, third-party control vendors for .NET will need to use a dedicated WinForms Designer SDK to develop custom control designers that run within the context of the OOP designer. We released a preview version of the SDK last month as a NuGet package, and you can download it here. We will update this package to provide IntelliSense in Q1 2022. There will also be a dedicated SDK blog post in the coming weeks.
Loeffelmann’s huge post dives deep into the finer details of the WinForms designer and how it works for those who want a full understanding of the technicalities, but he boils down the dense information into three key points:
- We removed the .NET WinForms designer from proc. While Visual Studio 2022 is 64-bit .NET Framework only, the new designer server process runs in the project’s respective bitness and as a .NET process. This, however, comes with some breaking changes, mostly around the creation of Control Designers.
- Data binding focuses on Object Information source. 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 for configuring object data sources.
- Control library authors, who need more design-time support for their controls than custom type editors, need WinForms Designer Extensibility SDK. Framework control designers no longer work without adjusting them to the new .NET WinForms designer OOP architecture.
“Let us know what topics you’d like to hear from us around WinForms Designer – the new Object data source functionality in the OOP designer and the WinForms Designer SDK are the topics already in the works and at the top of our list,” Loeffelmann said.