{"id":203,"date":"2024-03-17T11:42:07","date_gmt":"2024-03-17T11:42:07","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/03\/17\/winforms-in-a-64-bit-world-our-strategy-going-forward\/"},"modified":"2024-03-17T18:34:31","modified_gmt":"2024-03-17T18:34:31","slug":"winforms-in-a-64-bit-world-our-strategy-going-forward","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/03\/17\/winforms-in-a-64-bit-world-our-strategy-going-forward\/","title":{"rendered":"WinForms in a 64-Bit world \u2013 our strategy going forward"},"content":{"rendered":"

As a part of a community that thrives on innovation and growth, WinForms
\ndevelopers are often pushing boundaries to create new possibilities. Our
\ndevelopers are also responsible for the maintenance of mission critical line of
\nbusiness software, often well over a decade in the making. We value your trust
\nand your passion for creating excellent software solutions with our tools. As
\nyou may be aware, the transition from 32-bit to 64-bit in Visual Studio 2022 has
\nresulted in some complexities. We are aware that these changes are causing some
\nspeed bumps along your development journey, and we want to clarify these issues
\nby pointing out workarounds already available and our additional plans to
\naddress them.<\/p>\n

Embracing 64-bit: A Change for the Better<\/h2>\n

The decision to switch to a 64-bit platform is far more than a simple upgrade.
\nIt\u2019s a major improvement that helps Visual Studio work better in several ways.
\nOne of the biggest benefits is the ability to use more memory. In the 32-bit
\nversion, there were limits to how much memory Visual Studio could use, which
\noften led to slower performance or even errors when working on large projects.
\nThe 64-bit version removes these limitations, allowing Visual Studio to handle
\nlarger projects with greater efficiency.<\/p>\n\n

But it\u2019s not just about having access to more memory. The switch to 64-bit also
\nenables Visual Studio to make better use of your computer\u2019s processor,
\nparticularly of its multiple cores. Because a 64-bit application can process
\nmore data at once, it can use more cores simultaneously and effectively, which
\nleads to faster operations. This is particularly noticeable when building your
\nproject. If your project is large, with many files and lots of code, the build
\noperation can be considerably faster on 64-bit. This means less waiting around
\nfor builds to complete, which helps you get your work done quicker. But those
\nare not the only advantages. Others are:<\/p>\n

Compatibility with 64-bit libraries:<\/strong> There are numerous 64-bit libraries
\nand components that simply couldn\u2019t be used effectively with a 32-bit version of
\nVisual Studio. The 64-bit version enables better utilization and integration of
\nthese resources.<\/p>\n

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

Future-proofing:<\/strong> As technology continues to evolve, more and more
\napplications and operating systems are transitioning towards 64-bit
\narchitectures. By moving to 64-bit now, Visual Studio is following the wave,
\nensuring compatibility with future technological advancements.<\/p>\n

Larger Datasets:<\/strong> With 64-bit computing, you can work with significantly
\nlarger datasets that previously might have been impossible to handle due to
\nmemory restrictions. This is particularly advantageous at design-time in
\ndata-intensive fields like machine learning, big data analytics but also for
\ntasks which involve the processing of schemas of large and complex databases for
\nexample for code generation.<\/p>\n

Where does WinForms fit in?<\/h2>\n

These advantages are also true for the WinForms Designer. It is very common
\nfor WinForms application to reflect complex business cases. As a result, those
\napplications often contain of hundreds of Forms and UserControls which
\nthemselves can grow really big and complex. All of this leads to a lot of code
\nwhich needs to be generated as soon as a Form gets edited. One of the biggest
\nbeneficiaries of the 64-bit transition is therefore undoubtedly the WinForms
\nDesigner. The Designer leverages the ability to access more memory in the 64-bit
\narchitecture, greatly enhancing its performance and capacity to handle complex
\ndesign tasks.<\/p>\n

32-Bit legacy component challenges<\/h3>\n

All this said, we are fully aware that this advancement comes with certain
\nchallenges concerning components which are bound to a 32-Bit architecture and
\nwhich are used in the context of the Windows Forms designer for projects
\ntargeting .NET Framework Versions up to 4.8.1.<\/p>\n

The shift from 32-bit to 64-bit systems is not just about increasing power, but
\nit involves fundamental architectural changes. These changes directly affect how
\nwe manage .NET Framework versions and .NET Core applications. For instance, it
\nis not possible to host 32-bit exclusive components in a 64-bit process or .NET
\nCore types in a .NET Framework process. However, this should not be seen as an
\napproach that could have been avoided. Instead, it\u2019s a necessary part of the
\nnatural progression and evolution in technology.<\/p>\n

What are my options?<\/h3>\n

You have several avenues to consider, each with its own advantages:<\/p>\n

Move to .NET 8+<\/strong>: The most forward-thinking option, though, would be to
\nupgrade to .NET 8 or higher. The .NET 8+ environment is the future of (not only)
\nWinForms Application development and provides the most robust support,
\nespecially when it comes to third-party control vendors. With .NET 8+, you\u2019re
\nnot just keeping up with the times \u2013 you\u2019re staying ahead, ensuring that your
\napplications are ready for whatever the future brings.<\/p>\n

Use AnyCPU:<\/strong> Firstly, for the design time, switch everything to build with
\n\u2018AnyCPU\u2019. The \u2018AnyCPU\u2019 compile option in Visual Studio offers a versatile
\nsolution for addressing the 32-bit component issue in your WinForms project.
\nWhen your project is set to \u2018AnyCPU\u2019, Visual Studio will compile your
\napplication in such a way that it can run on both 32-bit and 64-bit platforms.
\nIn the context of design time, this flexibility means your process can run as
\n64-bit on a 64-bit system, allowing you to take full advantage of the benefits
\nof 64-bit Visual Studio, such as improved memory utilization and faster
\noperations. In many cases, this work quite well for projects, which require
\n32-Bit-runtime components. When it comes to runtime after a design session has
\nfinished, the \u2018Prefer 32-bit\u2019 project setting becomes key for compatibility with
\nolder 32-bit components or libraries. By enabling this setting, you\u2019re
\ninstructing the Common Language Runtime (CLR) to run your \u2018AnyCPU\u2019 compiled
\napplication in a 32-bit process, even on a 64-bit system. This provides an
\nenvironment where your 32-bit components function as expected, thereby
\nmaintaining the smooth operation of your application. While this approach does
\nimpose some of the 32-bit limitations, such as a smaller memory space, it offers
\nan effective solution for balancing between the need for 64-bit design time
\ncapabilities and the requirements of 32-bit components at runtime.<\/p>\n

Modernizing the 32-Bit components:<\/strong> If the first option is not feasible due
\nto the architecture of the 32-bit component, you might consider migrating away
\nfrom the 32-bit components. While this may require an initial investment of time
\nand resources, the benefits you stand to gain in the long run are significant.
\nTransitioning to a 64-bit environment offers not only better performance but
\nalso enhanced security. Moreover, it prepares your applications for future
\nupdates and advancements, thus ensuring their longevity.<\/p>\n

If all those options are not working for your special case, then there is the
\nout-of-process WinForms Designer as a final option:<\/p>\n

Adapting to the New Landscape: The Out-of-Process Designers<\/h2>\n

To support .NET Core 3.1 and above, we\u2019ve created an out-of-process version of
\nthe WinForms Designer; a separate process that can handle tasks that Visual
\nStudio cannot execute as a .NET Framework process. This essentially required us
\nto create an entirely new architecture and extensibility model to handle the
\ntwo types of processes simultaneously<\/a>.
\nUpgrading to .NET does have its challenges with changes in both the runtime and
\nin the new out-of-process designer. While we do have parity with the most
\nimportant design time functions, there are cases where legacy approaches don\u2019t
\nreally make sense to pursue any longer in the new technical landscape.<\/p>\n

The out-of-process designer allows us to circumvent the restrictions that
\nproblematic with the in-process design, namely the issues of hosting components
\nwhich are incompatible with the Target Framework of the hosting Designer, e.g.,
\nVisual Studio. This is accomplished by launching a new designer process, which
\nthen operates in the exact Target Framework Version, the WinForms project was
\nset up to target, allowing for greater flexibility in managing components of
\ndifferent architectures.<\/p>\n

In addition, the out-of-process designer permits us to provide support for
\nhigher versions of .NET, such as .NET 8, 9, and beyond. It does this by
\nallowing components to utilize features from these newer versions of .NET that
\nmay not be compatible with the .NET Framework.<\/p>\n

However, this also means that all the individual components and their control
\ndesigners must be adjusted to work across different process boundaries. When you
\nare using your own WinForms control libraries with highly customized design-time
\nsupport through dedicated Control Designers which provide custom CodeDOM
\nserialization, specialized type editors, customized adorner rendering or
\nindividualized Designer action items, you need to migrate your Designer code to
\nuse the WinForms Designer
\nSDK<\/a>.
\nWe\u2019ve made strides towards this with our stock controls for .NET (Core, 5+). And
\nwhat\u2019s also important: Most of our bigger third-party Control Library partners
\nalso provide their product to be used for .NET Versions 5, 6 and 7 \u2013 and
\nmodernized versions for .NET 8 are in the making.<\/p>\n

It\u2019s important to note that as we\u2019re addressing these issues, we\u2019re prioritizing
\ncomponents based on usage. Some of the lesser-used components in .NET Core have
\nhad their designer support deprecated in favor of more commonly used components.<\/p>\n

The Out-Of-Process Designer for .NET Framework Application with 32-bit Components<\/h2>\n

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

The out-of-process designer is engineered to spawn a separate 32-bit process
\nthat can host the components required for such applications. By doing so, it
\nsidesteps the incompatibility between the 64-bit environment of Visual Studio
\nand the 32-bit components. This design allows for smoother integration and
\ncompatibility, despite the disparity in system architectures.<\/p>\n

If you try top open a WinForms .NET Framework project, which has a reference to
\na 32-Bit-Component, Visual Studio will automatically bring up a dialog and ask,
\nif you want to open your project with the 32-Bit .NET Framework out-of-process designer.<\/p>\n\n

Just like its counterpart for .NET, the out-of-process designer for 32-Bit .NET
\nFramework<\/em> WinForms applications aims to provide the same design time experience,
\npreserving the ability to use existing, even legacy, 32-bit components. Despite
\nthe challenging task of bridging the architectural gap, we are committed to
\nensuring a smooth transition and maintaining the functionality you\u2019ve come to
\nrely upon, while also providing a pathway towards future upgrades and
\nenhancements.<\/p>\n

We understand that important legacy projects can rely on 32-bit ActiveX controls
\nand other legacy components that are currently incompatible with Visual Studio
\n2022, specifically for projects which are not targeting .NET (Core, 5+) but .NET Framework up
\nto Version 4.8.1. In these cases, the out-of-process designers can be the
\nsolution 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 \u2013 you
\nwould get the best of both worlds: 32-Bit compatibility at design time and
\nruntime and<\/em> the latest, most modern and most performant .NET version.<\/p>\n

It is<\/em> important to note<\/strong> that the updated out-of-process 32-Bit .NET Framework
\ndesigner will not<\/em> 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
\n.NET Core. That also means that highly customized Control Designers will not be
\ncompatible to the .NET Framework in-process designer out of the box. If you use
\ncustom control libraries from 3rd parties you need to check if they offer
\nversions which support the out-of-process .NET Framework<\/em> Designer.<\/p>\n

Supporting Legacy Components: Our Commitment and Plans<\/h2>\n

The out-of-process designers are where we are putting in most of our efforts
\ngoing forward. And here is the planning of our road map for this current year<\/em>:<\/p>\n

Improving the 32-Bit Framework out-of-process designer:<\/strong> This designer will
\nbe the choice for maintaining projects, which cannot be migrated to .NET
\n(Core, 5+), but depend on legacy 32-Bit components. This designer will not
\nhave feature parity with the in-process designer, but we will be adding more
\nfeatures as we see the customer demand for it. Note that the 32-Bit-Framework
\nDesigner is in Preview already and can be activated through the Tools\/Option<\/em>
\npage.<\/p>\n

For the Visual Studio 2022 version 17.9 we released a feature
\nwhich assists you to easily choose whether a .NET Framework project should be opened
\nfor the classic Visual Studio-in-process designer or the out-of-process designers.
\nThe differences compared to the classic WinForms in-process-designer will be:<\/p>\n

You will be able to open and design Forms and UserControls which are targeting
\n.NET Framework (up to version 4.8.1) and rely on 32-bit-based ActiveX
\ncomponents or most other reasons, which would force the resulting assembly to
\nbe 32-Bit in the Designer.<\/p>\n

If you are depending on special 3rd party control libraries for projects which
\nrely on legacy 32-bit components, you cannot use the same versions of those
\nlibraries which the 3rd party vendors provide for the classic in-process
\ndesigner. Check with your control library vendor, if they provide an updated
\nversion for the .NET Framework out-of-process designer.<\/p>\n

The typed DataSet designer and SQL Server query editor in the context of
\ndesigned DataSets will only remain available for the classic in-process
\ndesigner. We will, however, introduce updated features later this year, which
\nmake it easier and possible to consume<\/strong> Data Sources based on existing
\nTyped DataSets, so that maintaining Data Binding scenarios based on existing
\ndata sources will continue to be supported. We have no plans, however, at this
\ntime to support the classic Data Source tool windows in the .NET Framework
\nout-of-process designer.<\/p>\n

Data Sources based on classic SOAP Web services will not be supported by the
\nout-of-process designer for either .NET or .NET Framework applications.<\/p>\n

Providing the infrastructure for Root Designers: Third party vendors and
\ncontrol library authors rely on Root Designers \u2013 for example when they want to
\nmigrate their report designers from .NET Framework to .NET Core. By adding
\nroot designer support to the out-of-process designer, we\u2019ll enable control
\nauthors to modernize their powerful reporting designers and other document
\ndesigner types and bring them to .NET 6, 7 and 8+. We have, however, no plans
\nat this time, to support custom Root Designers for the .NET Framework
\nout-of-process Designer.<\/p>\n

Moving Forward: A Collaborative Effort<\/h2>\n

The transition to a 64-bit system is a significant milestone that requires a new
\napproach, innovative solutions, and patience. As mentioned before, this is not a
\nquick bug fix; rather, it\u2019s a transition that we need to manage together as a
\ncommunity.<\/p>\n

We are committed to making this journey as smooth as possible for you. Your
\nfeedback is invaluable, and it helps us identify the areas where we need to
\nfocus our efforts. We have a road map and we\u2019re making progress, but the
\ntimeline for completion depends on the unique challenges that you bring to our
\nattention.<\/p>\n

In conclusion, we understand the complexities you\u2019re facing, and we want to
\nreassure you that we\u2019re making strides in addressing these challenges. Remember,
\nchange often comes with a bit of discomfort, but it paves the way for growth and
\nbetter outcomes. We want to underscore the importance of your active engagement
\nin this ongoing transition. As we continually strive to improve and fine-tune
\nthe 64-bit designer and our out-of-process designer support, your feedback and
\nerror reports are invaluable. If you encounter any specific issues while using
\nWinForms, we strongly encourage you to report them directly in the WinForms
\nrepository on GitHub or via the feedback feature of Visual Studio. Detailed,
\nconcrete issue reports, especially those that include information about the
\nenvironment, steps to reproduce, and the specific error messages, help us
\nimmensely in identifying and addressing problems more effectively and rapidly.
\nYour participation in this process is crucial for the successful development of
\na more robust and efficient Visual Studio, since the technology, legacy
\n32-Bit-components are based all, is in many cases 20 years old and older.<\/p>\n

Final Thoughts<\/h2>\n

The journey from 32-bit to 64-bit has been a complex one and not without its
\nchallenges. We\u2019re committed to making this transition as smooth as possible for
\nall our users, but we understand that there will be bumps along the way.<\/p>\n

Thank you for your support and commitment as we push forward to a more capable
\nand versatile WinForms ecosystem, and as always\u2026<\/p>\n

\u2026happy coding!<\/p>\n

The post WinForms in a 64-Bit world \u2013 our strategy going forward<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

As a part of a community that thrives on innovation and growth, WinForms developers are often pushing boundaries to create […]<\/p>\n","protected":false},"author":1,"featured_media":204,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=203"}],"version-history":[{"count":1,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/203\/revisions"}],"predecessor-version":[{"id":219,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/203\/revisions\/219"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/204"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}