An improved 32-bit out of process designer is Microsoft’s solution to broken support for legacy 32-bit Windows Forms applications, however, it will never achieve parity with previous versions, according to a new post from the team.
Windows Forms is the oldest framework for .NET desktop applications and remains widely used. The framework was popular for developing custom business applications, and maintaining these is a common requirement for enterprise developers.
In November 2021 Microsoft released Visual Studio 2022, the first 64-bit version, and in doing so it broke the 32-bit designer for Windows Forms. A long thread in Microsoft’s feedback forums described the issue: a Windows Forms .NET Framework project targeting x86 raised a “white screen of death” error in the designer, reporting it “could not load file or assembly.”
Microsoft principal software engineering manager Merrie McGaw explained at the time that the Windows Forms designer for .NET Framework applications runs in-process “to minimize breaking changes for 3rd party controls that interact with Visual Studio.” Therefore, 32-bit components cannot be loaded “and you will see a white error screen instead.” Switch your components to x64, said McGaw, and “if you are using a third-party component, reach out to the author and ask them to provide an x64 or Any CPU version.”
Following this advice is often impractical, and many developers had to do the next best thing of sticking with Visual Studio 2019 for these projects. For example, one developer commented that “our organization has 3.5 million robot connections that run nearly 800 third-party modules created by 400 partners. The logistics for our platform transitioning to a newer .Net version is incredibly costly and time-consuming for ourselves and our customers.”
The problem remains, though Microsoft devised a partial solution in 2022. This involved replicating an approach first taken for Windows Forms on .NET Core, where there is an out of process designer. The out of process designer can run as 32-bit, but there is a lot of complexity around how to communicate with the rest of Visual Studio, discussed here, where senior software engineer Klaus Loeffelmann described the proxies, services and cross-process calls required to handle basic operations like showing the properties of a button. The designer, which was for .NET Core but not .NET Framework, was less stable than others in Visual Studio; but it was better than nothing.
Microsoft is now introducing a second out of process designer, this time for .NET Framework Windows Forms applications. “If you try to 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 the latest post.
Loeffelmann added that these out of process designers “are where we are putting in most of our efforts going forward.” That said, the 32-bit .NET Framework designer “will not have feature parity with the in-process designer,” though features will be added based on feedback. Specifically though, features including the typed DataSet designer and data sources based on SOAP web services will not be supported.
Developers may feel that sticking with Visual Studio 2019 remains the best option; but those who wish to try the new approach can check an option in Visual Studio 2022, under Tools – Options – Environment – Preview Features, that will enable the 32-bit .NET Framework designer.
Much of Loeffelmann’s post is devoted to the general advantages of 64-bit Visual Studio and the “challenging task of bridging the architectural gap.” All true; but there is a reason there are so many Windows Forms, and even Visual Basic 6.0 applications still in use, relating to the many changes of direction the company has taken regarding desktop frameworks, and the lack of any easy migration path.
The more positive take is that Microsoft continues to put engineering effort into supporting Windows Forms, even if not to the extent that developers would prefer, suggesting that applications built with this technology will continue to work for a long time to come.