Dynamics GP Addins and Visual Studio 2022 error adding new form

The designer could not be shown for this file because none of the classes within it can be designed error

tldr;
To edit windows/dynamics gp forms in 32 bit mode for Dynamics GP Add-ins using Visual Studio 2022, you must use the following version or newer:
VS 2022 17.9.0 Preview 2 (note Version 17.10.0 Preview 1.0 seems to have broken this functionality for me)
Microsoft have done a lot of work on an out of process forms designer to support 32 bit applications, but it is only included in this version onwards (or preview 1 with feature switch).

Trying to use Visual studio 2022 or older and getting the error below from the windows form deisgner? -read on as Microsoft have changed the engine for the forms designer in newer versions of Visual Studio for a 64bit version that causes problems with legacy applications or libraries.

“The designer could not be shown for this file because none of the classes within it can be designed. The designer inspected the following classes in the file: DynamicsGPForm1—The base class ‘Microsoft.Dexterity.Shell.DexUIForm’ could not be loaded. Ensure the assembly has been referenced and that all projects have been built.”

There are confirmations of this issue when using the visual studio add in template extension for Dynamics GP with Visual Studio 2022. You may experience the above error. This is observied in the following community posts too:
Building an application with VS 2022 fails when attempting to add Dynamics GP form. and Microsoft.Dexterity.Shell.DexUIForm

There was a major change with the introduction of Visual Studio 2022, a departure from previous versions of Visual Studio. Visual Studio went fully 64bit in this release, now running as a 64bit application. This means when a user is working inside Visual Studio, everything in the IDE is running as a 64bit application, this is a push towards the general adoption of 64bit as the new standard normal. This is all great except for the fact that Dynamics GP is a 32bit application, and is not likely to become 64bit anytime soon.

When developing an add-In for Dynamics GP, the various Dynamics GP libraries that are referenced are Dynamics GP 32bit libraries. When a GP form is added to the solution the above error will occur as the GP form would normally be ran by Visual Studio, in design time in order to move controls and drop them onto the form visually (visual designer). However Visual Studio is running as 64bit and it is going to attempt to load 32bit code, this does not work. Hence the above error is raised by the designer.

This issue does not just happen for GP users, developers wishing to consume any 32 bit library or ActiveX/COM/OCX components will get the same issue. There were a number of "bug" reports around this after the launch of Visual Studio 2022, and these have now been consolidated down onto the following bug report. To be fair on Microsoft this is not really a bug, as this is the intended way it should work. WinForms .NET Framework Projects can't display the designer for 32bit references I would highly recommend reading this thread to get an understanding of the change and see the desperation of other developers on other products for a solution to this issue.

The "workaround"

In the thread WinForms .NET Framework Projects can't display the designer for 32bit references the work around is given, which is to make a project build target of both 32 bit and 64 bit, then swtich between them. Although annoying and clunky, it works for me, by creating a separate build configuration for the solution and each project targeting Any CPU, then clean/rebuild. This will allow the designer to work, then before building the dll to deploy to GP, change the project target back to 32bit, after any form design work is complete (close any forms that are open). There is also the suggestion to simply not use Visual Studio 2022 for 32bit Winform design, instead keep using Visual Studio 2019. However 2019 tries to push you onto 2022, with messages like, ‘Please update to Visual Studio 2022, we are not supporting Visual Studio 2019 any longer.’ , so who knows how long this is going to be practical as a solution.
There was also talk on the bug thread about using the Visual Studio Options>>Environment>>Preview Features>> Use the preview Windows Forms out-of-process designer for .NET apps option. I have had no success selecting this option and don't think this is applicable to Dynamics GP development.

Using Build>> Configuration Manager in Visual Studio, Use the <New..> option to create a new configuration for x86 and Any CPU, Copy settings from Any CPU or x86. It should end up with two options under both "Debug" and "Release" solution configurations. One should be x86 and the other Any CPU, as shown below.

Select Any CPU and clean build to do any design work, then before deployment or debugging with GP itself, it must be switched back to x86 so we get a 32bit application complied.

Below is the guts of the matter from the referenced thread above, in case it should vanish from the internet...

Visual Studio 2022 and WinForms 32-bit .NET Framework components

Visual Studio 2022 is the first Visual Studio that runs as a 64-bit application. We received lots of requests to make this change and now you can open, edit, run, and debug the biggest and most complex solutions without running out of memory. This switch required fundamental architectural changes and there were some scenarios related to .NET Framework 32-bit components that we could not make work in Windows Forms designer.

In order to support .NET Core 3.1 and above we had to create an out of process designer. For .NET Framework, the designer remained in-process. The reason for that decision was to minimize breaking changes for 3-rd party controls that interact with Visual Studio. Since Visual Studio is now 64-bit, the .NET Framework-based designer now also runs in 64-bit, which means 32-bit code cannot be loaded at design time any longer. At the same time, to load controls for .NET Core, we created a new designer that runs out of process. Since that process can run as either a 32-bit or 64-bit process, it can be used with 32-bit controls . . So, for .NET 6, .NET 5, and .NET Core applications you have full designer support . But if you have a .NET Framework application that is referencing a 32-bit component, this component cannot be loaded in Visual Studio 2022 Windows Forms designer, and you will see a white error screen instead. This will not affect your end users, as your application will run just fine, it only affects the designer experience inside of Visual Studio.

In the future, we plan to add support for .NET Framework projects to the out of process designer. Once that support is available, it will be possible to load forms that have 32-bit specific dependencies in the designer.

Meanwhile there are a few ways to make your Forms show in the designer:

• You can simply keep using Visual Studio 2019 for forms that have references to 32-bit components until we add support for .NET Framework projects to the out of process designer.

• If you are an author of the component you are using, rebuild it for ‘x64’ for native components or ‘Any CPU’ for managed code. For managed code, the procedure should be very straight forward.

• If a 32-bit component cannot be rebuilt, you can create a “design” configuration of the project, which targets 64-bits and where the 32-bit component is replaced with a 64-bit placeholder. This particular component will not be available at design time but the rest of the UI will be.

• If you are using a third-party component, reach out to the author and ask them to provide an ‘x64’ or ‘Any CPU’-version of it.

• For some cases, such as Visual Basic 6, producing 64-bit is not an option because they are legacy controls that don’t have an implementation on 64-bit CPU. We would suggest finding a .NET substitute for the component that provides similar functionality.

Then...

We hear and understand your concerns regarding the 32-bit references. Due to the way the Framework WinForms Designer was created, the form you are designing runs in the same process as Visual Studio runs in. Unfortunately, with the move to 64bit it meant that references now must be of an architecture that x64 can work with (AnyCPU or 64-bit). If you have access to the source code of the original projects the key is to design them with the reference as AnyCPU, even if you ultimately build and release a 32bit version of the reference.

The only way for us to fix this in WinForms is a rearchitecting of the designer entirely to run out of the process of Visual Studio - and if it were to do that, you would be able to design with your references in whatever architecture suited your needs. Unfortunately moving the designer out of process is far more than a bug fix; it’s an entire re-architecting of how the design surface in one process communicates with the Visual Studio process and passes the information back and forth about control properties. We have been working on creating an out-of-process WinForms Designer for .NET applications, and we’re getting pretty happy with the user experience in this last VS release. That said, there is still more work to be done to support .NET Framework projects and it doesn’t preclude the need to do something with the references that are causing you trouble now. They may need to be built against this new architecture for full support in the out of process designer.

We’re working hard on investigating what it will take to move the Framework designer out of process like the .NET WinForms Designer, and I will circle back on this thread with more information as I have it. I’m unable to provide a timeline yet, but once we’ve completed our investigations and done some prototype work we should have a better idea about the timeline of the project. Stay tuned for a WinForms blog post early in the new year which will give you a little insight into how we got an out of process designer to work, and future blog posts about the details of the new architecture.

Update 07th Dec 2022

Klaus Loeffelmann [MSFT] has posted a new comment on Developer Community

Hi everyone,
My name is Klaus, I'm a Dev on the WinForms team and in the interest of transparency I would like to explain the overall issue from a somewhat technical perspective.
The problem we are discussing in this thread is multifaceted and we are not talking about a simple bug-fix here. We are talking about conceptual work that was started in the middle of last year and will - even for quite some time - continue well into the new year.
Allow me to shed some light on the technical background, so that issue can be understood a little better and also how we in the WinForms team can solve the problem satisfactorily only if we continue to work together with the community, both here and on GitHub. (And I say continue here, because as most of you know: the WinForms runtime is open source, its development is happening in the open on GitHub in the WinForms Github Repo, and it has become customary over the last 2 years, that customers and developers also communicate with us directly there about WinForms Designer issues.)
Before I started working at Microsoft on the WinForms team, I was an MVP and a .NET Consultant. As an MVP, I had the chance to be in constant contact with the C#, WinForms and WPF product teams. One of the features that we absolutely wanted to have in the enterprise environment at the time, already some 6 years (and even longer ago), in fact almost needed, was a 64-bit Visual Studio version in order to be able to use the full potential of modern development machines. 32-Bit Visual Studio slowed us down immensely, especially for our typical 5 million+ lines of code projects. At the time, many of us technically experienced managers of larger development projects - legacy as well as new developments projects - were aware that changing legacy designers to 64-bit in particular might have problems when dealing with 32-bit-only environments. That's why we as software consultants tried years ago to convert old components based on 32-bit Access databases or MFC-ActiveX components or even (but often, yes, I know!) VB6-ActiveX components, and to replace them with 64-bit or "AnyCPU" equivalents.
The core problem around Visual Studio: Framework versions. You simply cannot host 32-bit only components in a 64-bit process. That's not a bug, that's not a design error - that's in the very nature of things. The same applies to .NET Core/5/6/7/8+ Apps and .NET Framework. A .NET Core type cannot be projected onto or in a .NET Framework process because it represents a higher version and may have new properties and functionalities that the .NET Framework simply does not know about.
An example: With .NET 7 there is a new Command property for WinForms Buttons, which we use to enable data binding to ViewModels that provide ICommand Definitions (like we do in WPF or other XAML UI stacks) as a binding target. In .NET Core 3.1 we added a PlaceHolderText property to the TextBox control. This does not exist in the .NET Framework (of any version). So, a WinForms designer hosted in Visual Studio will NEVER be able to provide a property window that reflects the PlaceHolderText property, because the TextBox in .NET Framework 4.7.2, in whose context Visual Studio is running, does not know anything about this property. And will never know it. We don't get a new .NET type to run in the .NET Framework process, that's the nature of things.
And now, if we're applying this to .NET Framework 32-bit and .NET Framework 64-bit: We also cannot run pure 32-bit components in a 64-bit process. Or the other way around. Does that mean there are no more .NET applications or 32-bit applications for .NET Framework because Visual Studio only runs in a .NET Framework 64-bit process? No. Here is our general approach to solve this problem:
For .NET (Core) we took part of the WinForms designer out of the .NET Framework process. For WinForms applications that target .NET Core, there is another .NET Designer process that then does everything based on a process targeting the .NET Version that Visual Studio itself simply cannot do as a NET Framework process. At the same time, this also means that the individual components and control designers (of which each control and component in WinForms brings its own) must all be adapted accordingly so that they can communicate with the other process beyond the process boundaries. We have already done this for most of the stock controls for the .NET Core scenarios - but not yet for the 32-bit/64-bit combination. And there are also certain Visual Studio services, like the Data Source Provider Service, which are currently not able to talk to the different process. This is the reason why for example the classic Data Source Window is missing for .NET projects, and we provided a different route for .NET at the time.
In particular, the components that we know are rarely used anymore in .NET Core scenarios, we have deprecated Designer support in favor of more important components. Of course, that also explains why every developer has a different view of the current status quo in terms of backward compatibility.
The question folks on this thread might have in this context: why didn't we do all this in advance before the 64-bit conversion of Visual Studio? It’s simple: Because many customers (including myself at the time being on the “other side”) would rather have 64-bit support in VS immediately, since they are and were much more dependent on the 64-bit need than on the not-yet-resolved 32-bit dependency. They say: For what's still 32-bit, we'll use VS2019, either until we've made the switch, or the out-of-process WinForms Designer is ready to handle the most common 32-bit scenarios.
And that's the status quo. We already have a rudimentary out-of-process .NET Framework 32-bit WinForms Designer under Preview Features in VS 2022.5 Preview 1, which we will continue to make more and more 32-bit legacy-compatible over the next year. You can test this out under Tools->Options -> Preview Features. So, the situation is constantly improving, and of course we will be approaching a feasible compromise spot from both sides, so to speak: Many Third-party manufacturers of exceptional niche components - if the manufacturer still exists - will certainly continue migrating their components. Developers who develop with Visual Studio will make their applications more and more 64-bit compatible and will replace older components. And we will strive to support the most important 32-bit components and scenarios in the out-of-process designer.
But all this is also the reason why we see so many different reactions and “status reports” here: It’s not about fixing the one bug in this scenario, and there is certainly not just one single course of action which would make everything work. It’s about identifying the most diverse scenarios one after the other, prioritizing them and then making them intrinsically work again. And for that we need to know and understand those scenarios or “missing” components. We have already implemented many, in addition some are already on our backlog, and we are continuing to implement them or have already implemented them, but not yet released. For many developers, their scenarios already work (again) in the Out-Of-Process Designer framework. For others: not yet. And to be honest and transparent and to say it very clearly: We also have to reckon with components or scenarios that we can no longer make work at all, because the underlying core technologies used are simply too old and raise security issues that we simply must not risk deploying.
My ask at this point is therefore to report your personal scenarios component setups in our .NET WinForms Runtime GitHub repo, if they fail to work as expected, so that we can prioritize specific scenarios according to importance and we can plan our further work on the out-of-process designer. We have introduced a new issue label "32-Bit Designer support" you can filter the issues with, and check whether there is already corresponding issue created.
image.png
And if so, please indicate that you’re affected by setting an appropriate icon
image.png
so that we have an idea of how many developers are affected by which feature and can better prioritize our work. If you need the ability to reply to us directly but privately, please file a new VS feedback issue and it will get to us. I would be sure to say “Issue w/WinForms out of process designer in 32bit scenario” or something to that effect.
We're really working here to get the cow off the ice as quickly as possible, as they say in German. But the better we work together in this respect, the faster we can make progress here. Until then, trying to target AnyCPU for all projects in Visual Studio 2022 for many .NET Framework-only scenarios or continue using Visual Studio 2019 for the time being remains your alternative for problematic scenarios.
In addition to what all that said, we are currently also discussing alternative workarounds, which we would then publish in corresponding blog posts in the new year. I'll also be updating more links to example issues here on GitHub in the future and - as they become available – links to upcoming blogs here.
Until then,
thank you for your help!
Klaus

Update Sept 2023
There have been some further updates to the thread before this linked item below, so it is worth reading the whole thread...
https://developercommunity.visualstudio.com/t/WinForms-NET-Framework-Projects-cant-d/1601210#T-N10465538

so it looks like a solution is not far away...