News

Some 5 Years In, 'New' WinForms Designer Still Not There

• By David Ramel
• 02/28/2024

First, it was problems with moving from the proprietary .NET Framework to the open source, cross-platform .NET Core (now just .NET).

Then, it was problems with Visual Studio 2022 moving to the 64-bit world.

So, almost five years after Microsoft's dev team started working on the first preview of the Windows Forms Designer for .NET Core, it's still not a first-class offering for Visual Studio 2022, with the company last week offering a WinForms in a 64-Bit world update that includes a mishmash of alternatives for developers somehow stuck working with technology more than 20 years old.

Here's what Olia Gavrysh, senior product manager, .NET, said in announcing that Preview 1 in September 2019:

"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. 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."

Fast forward to February 2024 with Klaus Loeffelmann, senior software engineer, .NET/Desktop UI/Windows Forms:

"The journey from 32-bit to 64-bit has been a complex one and not without its challenges. We're committed to making this transition as smooth as possible for all our users, but we understand that there will be bumps along the way."

Several alternatives/workarounds were offered to smooth that journey, with the latest being a new 32-bit out-of-process .NET Framework designer to join the existing out-of-process WinForms designer, the latter being a separate process that was earlier created to handle tasks that Visual Studio cannot execute as a .NET Framework process. That complicated project addressed just one part of the complex problem in a specific scenario for 32-bit WinForms applications built for .NET Framework.

"Just like its counterpart for .NET, the out-of-process designer for 32-Bit .NET Framework WinForms applications aims to provide the same design time experience, preserving the ability to use existing, even legacy, 32-bit components," Loeffelmann said of the new approach.

However, of course, it's not the solution devs just want in order to just get their legacy work done as efficiently as possible while maintaining functional parity with old tech.

Styling his comments for emphasis, Loeffelmann explained: "It is important to note that the updated out-of-process 32-Bit .NET Framework designer will not achieve full parity with the old in-process .NET Framework Designer due to the same architectural differences mentioned for the out-of-process designer for .NET Core. That also means that highly customized Control Designers will not be compatible to the .NET Framework in-process designer out of the box. If you use custom control libraries from 3rd parties you need to check if they offer versions which support the out-of-process .NET Framework Designer."

Among the many workarounds and alternatives to address 32-bit legacy component challenges outlined in his post, Loeffelmann proposed the option for developers to simply adopt the modern .NET offering.

"The most forward-thinking option, though, would be to upgrade to .NET 8 or higher," he said. "The .NET 8+ environment is the future of (not only) WinForms Application development and provides the most robust support, especially when it comes to third-party control vendors. With .NET 8+, you're not just keeping up with the times -- you're staying ahead, ensuring that your applications are ready for whatever the future brings."

For the present, however, the new out-of-process designer for .NET Framework applications with 32-bit components will allow a developer to choose to use it or not.

"If you try top open a WinForms .NET Framework project, which has a reference to a 32-Bit-Component, Visual Studio will automatically bring up a dialog and ask, if you want to open your project with the 32-Bit .NET Framework out-of-process designer," said Loeffelmann in reference to the screenshot above.

He explained what the new approach's differences compared to the classic WinForms in-process-designer will be:

• You will be able to open and design Forms and UserControls which are targeting .NET Framework (up to version 4.8.1) and rely on 32-bit-based ActiveX components or most other reasons, which would force the resulting assembly to be 32-Bit in the Designer.
• If you are depending on special 3rd party control libraries for projects which rely on legacy 32-bit components, you cannot use the same versions of those libraries which the 3rd party vendors provide for the classic in-process designer. Check with your control library vendor, if they provide an updated version for the .NET Framework out-of-process designer.
• The typed DataSet designer and SQL Server query editor in the context of designed DataSets will only remain available for the classic in-process designer. We will, however, introduce updated features later this year, which make it easier and possible to consume Data Sources based on existing Typed DataSets, so that maintaining Data Binding scenarios based on existing data sources will continue to be supported. We have no plans, however, at this time to support the classic Data Source tool windows in the .NET Framework out-of-process designer.
• Data Sources based on classic SOAP Web services will not be supported by the out-of-process designer for either .NET or .NET Framework applications.
• Providing the infrastructure for Root Designers: Third party vendors and control library authors rely on Root Designers -- for example when they want to migrate their report designers from .NET Framework to .NET Core. By adding root designer support to the out-of-process designer, we'll enable control authors to modernize their powerful reporting designers and other document designer types and bring them to .NET 6, 7 and 8+. We have, however, no plans at this time, to support custom Root Designers for the .NET Framework out-of-process Designer.

Going forward, he outlined plans to improve the 32-bit Framework out-of-process designer and sought community involvement.

That jives with "Visual Studio 2022 Roadmap" documentation updated Feb. 14 that says: "On the road ahead for WinForms support in Visual Studio, we'll continue to focus on the quality and performance of the designers."