WinForms in a 64-Bit world – our strategy going forward

As a part of a community that thrives on innovation and growth, WinForms developers are often pushing boundaries to create new possibilities. Our developers are also responsible for the maintenance of mission critical line of business software, often well over a decade in the making. We value your trust and your passion for creating excellent software solutions with our tools. As you may be aware, the transition from 32-bit to 64-bit in Visual Studio 2022 has resulted in some complexities. We are aware that these changes are causing some speed bumps along your development journey, and we want to clarify these issues by pointing out workarounds already available and our additional plans to address them.

Embracing 64-bit: A Change for the Better

The decision to switch to a 64-bit platform is far more than a simple upgrade. It’s a major improvement that helps Visual Studio work better in several ways. One of the biggest benefits is the ability to use more memory. In the 32-bit version, there were limits to how much memory Visual Studio could use, which often led to slower performance or even errors when working on large projects. The 64-bit version removes these limitations, allowing Visual Studio to handle larger projects with greater efficiency.

But it’s not just about having access to more memory. The switch to 64-bit also enables Visual Studio to make better use of your computer’s processor, particularly of its multiple cores. Because a 64-bit application can process more data at once, it can use more cores simultaneously and effectively, which leads to faster operations. This is particularly noticeable when building your project. If your project is large, with many files and lots of code, the build operation can be considerably faster on 64-bit. This means less waiting around for builds to complete, which helps you get your work done quicker. But those are not the only advantages. Others are:

• Compatibility with 64-bit libraries: There are numerous 64-bit libraries and components that simply couldn’t be used effectively with a 32-bit version of Visual Studio. The 64-bit version enables better utilization and integration of these resources.

• Enhanced Security: 64-bit systems have some built-in security advantages over 32-bit ones, including a feature called Address Space Layout Randomization (ASLR) that makes it more difficult for malicious code to exploit the system.

• Future-proofing: As technology continues to evolve, more and more applications and operating systems are transitioning towards 64-bit architectures. By moving to 64-bit now, Visual Studio is following the wave, ensuring compatibility with future technological advancements.

• Larger Datasets: With 64-bit computing, you can work with significantly larger datasets that previously might have been impossible to handle due to memory restrictions. This is particularly advantageous at design-time in data-intensive fields like machine learning, big data analytics but also for tasks which involve the processing of schemas of large and complex databases for example for code generation.

Where does WinForms fit in?

These advantages are also true for the WinForms Designer. It is very common for WinForms application to reflect complex business cases. As a result, those applications often contain of hundreds of Forms and UserControls which themselves can grow really big and complex. All of this leads to a lot of code which needs to be generated as soon as a Form gets edited. One of the biggest beneficiaries of the 64-bit transition is therefore undoubtedly the WinForms Designer. The Designer leverages the ability to access more memory in the 64-bit architecture, greatly enhancing its performance and capacity to handle complex design tasks.

32-Bit legacy component challenges

All this said, we are fully aware that this advancement comes with certain challenges concerning components which are bound to a 32-Bit architecture and which are used in the context of the Windows Forms designer for projects targeting .NET Framework Versions up to 4.8.1.

The shift from 32-bit to 64-bit systems is not just about increasing power, but it involves fundamental architectural changes. These changes directly affect how we manage .NET Framework versions and .NET Core applications. For instance, it is not possible to host 32-bit exclusive components in a 64-bit process or .NET Core types in a .NET Framework process. However, this should not be seen as an approach that could have been avoided. Instead, it’s a necessary part of the natural progression and evolution in technology.

What are my options?

You have several avenues to consider, each with its own advantages:

• Move to .NET 8+: The most forward-thinking option, though, would be to upgrade to .NET 8 or higher. 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.

• Use AnyCPU: Firstly, for the design time, switch everything to build with ‘AnyCPU’. The ‘AnyCPU’ compile option in Visual Studio offers a versatile solution for addressing the 32-bit component issue in your WinForms project. When your project is set to ‘AnyCPU’, Visual Studio will compile your application in such a way that it can run on both 32-bit and 64-bit platforms. In the context of design time, this flexibility means your process can run as 64-bit on a 64-bit system, allowing you to take full advantage of the benefits of 64-bit Visual Studio, such as improved memory utilization and faster operations. In many cases, this work quite well for projects, which require 32-Bit-runtime components. When it comes to runtime after a design session has finished, the ‘Prefer 32-bit’ project setting becomes key for compatibility with older 32-bit components or libraries. By enabling this setting, you’re instructing the Common Language Runtime (CLR) to run your ‘AnyCPU’ compiled application in a 32-bit process, even on a 64-bit system. This provides an environment where your 32-bit components function as expected, thereby maintaining the smooth operation of your application. While this approach does impose some of the 32-bit limitations, such as a smaller memory space, it offers an effective solution for balancing between the need for 64-bit design time capabilities and the requirements of 32-bit components at runtime.

• Modernizing the 32-Bit components: If the first option is not feasible due to the architecture of the 32-bit component, you might consider migrating away from the 32-bit components. While this may require an initial investment of time and resources, the benefits you stand to gain in the long run are significant. Transitioning to a 64-bit environment offers not only better performance but also enhanced security. Moreover, it prepares your applications for future updates and advancements, thus ensuring their longevity.

If all those options are not working for your special case, then there is the out-of-process WinForms Designer as a final option:

Adapting to the New Landscape: The Out-of-Process Designers

To support .NET Core 3.1 and above, we’ve created an out-of-process version of the WinForms Designer; a separate process that can handle tasks that Visual Studio cannot execute as a .NET Framework process. This essentially required us to create an entirely new architecture and extensibility model to handle the two types of processes simultaneously. Upgrading to .NET does have its challenges with changes in both the runtime and in the new out-of-process designer. While we do have parity with the most important design time functions, there are cases where legacy approaches don’t really make sense to pursue any longer in the new technical landscape.

The out-of-process designer allows us to circumvent the restrictions that problematic with the in-process design, namely the issues of hosting components which are incompatible with the Target Framework of the hosting Designer, e.g., Visual Studio. This is accomplished by launching a new designer process, which then operates in the exact Target Framework Version, the WinForms project was set up to target, allowing for greater flexibility in managing components of different architectures.

In addition, the out-of-process designer permits us to provide support for higher versions of .NET, such as .NET 8, 9, and beyond. It does this by allowing components to utilize features from these newer versions of .NET that may not be compatible with the .NET Framework.

However, this also means that all the individual components and their control designers must be adjusted to work across different process boundaries. When you are using your own WinForms control libraries with highly customized design-time support through dedicated Control Designers which provide custom CodeDOM serialization, specialized type editors, customized adorner rendering or individualized Designer action items, you need to migrate your Designer code to use the WinForms Designer SDK. We’ve made strides towards this with our stock controls for .NET (Core, 5+). And what’s also important: Most of our bigger third-party Control Library partners also provide their product to be used for .NET Versions 5, 6 and 7 – and modernized versions for .NET 8 are in the making.

It’s important to note that as we’re addressing these issues, we’re prioritizing components based on usage. Some of the lesser-used components in .NET Core have had their designer support deprecated in favor of more commonly used components.

The Out-Of-Process Designer for .NET Framework Application with 32-bit Components

We saw that more people needed support with designing WinForms applications for the 32-Bit .NET Framework, since these applications used parts that only worked in a 32-bit process. That was the reason, we adapted the approach of the WinForms out-of-process-designer for .NET and are introducing the 32-Bit out-of-process .NET Framework designer based of this.

The out-of-process designer is engineered to spawn a separate 32-bit process that can host the components required for such applications. By doing so, it sidesteps the incompatibility between the 64-bit environment of Visual Studio and the 32-bit components. This design allows for smoother integration and compatibility, despite the disparity in system architectures.

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.

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. Despite the challenging task of bridging the architectural gap, we are committed to ensuring a smooth transition and maintaining the functionality you’ve come to rely upon, while also providing a pathway towards future upgrades and enhancements.

We understand that important legacy projects can rely on 32-bit ActiveX controls and other legacy components that are currently incompatible with Visual Studio 2022, specifically for projects which are not targeting .NET (Core, 5+) but .NET Framework up to Version 4.8.1. In these cases, the out-of-process designers can be the solution for many use cases. But note, that also the .NET (6+) WinForms out-of-process designer should be considered the preferred and best-practice way forward – you would get the best of both worlds: 32-Bit compatibility at design time and runtime and the latest, most modern and most performant .NET version.

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.

Supporting Legacy Components: Our Commitment and Plans

The out-of-process designers are where we are putting in most of our efforts going forward. And here is the planning of our road map for this current year:

• Improving the 32-Bit Framework out-of-process designer: This designer will be the choice for maintaining projects, which cannot be migrated to .NET (Core, 5+), but depend on legacy 32-Bit components. This designer will not have feature parity with the in-process designer, but we will be adding more features as we see the customer demand for it. Note that the 32-Bit-Framework Designer is in Preview already and can be activated through the Tools/Option page.

For the Visual Studio 2022 version 17.9 we released a feature which assists you to easily choose whether a .NET Framework project should be opened for the classic Visual Studio-in-process designer or the out-of-process designers. The 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.

Moving Forward: A Collaborative Effort

The transition to a 64-bit system is a significant milestone that requires a new approach, innovative solutions, and patience. As mentioned before, this is not a quick bug fix; rather, it’s a transition that we need to manage together as a community.

We are committed to making this journey as smooth as possible for you. Your feedback is invaluable, and it helps us identify the areas where we need to focus our efforts. We have a road map and we’re making progress, but the timeline for completion depends on the unique challenges that you bring to our attention.

In conclusion, we understand the complexities you’re facing, and we want to reassure you that we’re making strides in addressing these challenges. Remember, change often comes with a bit of discomfort, but it paves the way for growth and better outcomes. We want to underscore the importance of your active engagement in this ongoing transition. As we continually strive to improve and fine-tune the 64-bit designer and our out-of-process designer support, your feedback and error reports are invaluable. If you encounter any specific issues while using WinForms, we strongly encourage you to report them directly in the WinForms repository on GitHub or via the feedback feature of Visual Studio. Detailed, concrete issue reports, especially those that include information about the environment, steps to reproduce, and the specific error messages, help us immensely in identifying and addressing problems more effectively and rapidly. Your participation in this process is crucial for the successful development of a more robust and efficient Visual Studio, since the technology, legacy 32-Bit-components are based all, is in many cases 20 years old and older.

Final Thoughts

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.

Thank you for your support and commitment as we push forward to a more capable and versatile WinForms ecosystem, and as always…

…happy coding!