“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.”
When using the visual studio add in template extension for Dynamics GP with Visual Studio 2022, you may experience the above error. This is noted in the following community posts:
Building an application with VS 2022 fails when attempting to add Dynamics GP form.
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 behaviour. 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 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.