Up until VS2022, Visual Studio itself was always a 32-bit (x86) application. It could be used to compile x86 and x64 solutions (as well as AnyCPU though we don't support AnyCPU in DotImage so we'll leave the discussion to x86/x64), but natively, it was 32 bit and this led to some issues
Issues Due to 32 bit VS2019 and Narlier
In 32 bit versions of Visual Studio, when building windows forms or WPF apps etc where the Form Designer is in use. The designer itself was running 32 bit only no matter what platform target (x86, AnyCPU, x64) you might target. This led to a situation where if you were targeting x64 with Atalasoft x64 DLLs, you'd find that the Visual Studio Form designer would refuse to load your form and gave a warning about possibly breaking things if you continued.
The root cause was that when targeting x64 DLLs, visual studio could run MSBuild in the right bitness but the designer only worked in 32 bit - with our 64 bit dlls, the designer was not able to access the controls, and thus the workaround/ fix was to design using our x86 DLLs and target x86 and switch your app to target x64 only after finishing the design work.
In 32 bit versions of Visual Studio, the License Compiler (lc.exe) that would execute when embedding licenses (parsing the licenses.licx file, it would see it had work to do and invoke lc.exe) and although it "knew" to run the MSBuild in 64 bit context, for some reason, it did not automatically select the 64 bit version of LC.exe for license compiling
The fix was to use a workaround of manually specifying the correct tool path
INFO: Workaround for a License Compiler Exception When Targeting x64 in .NET Framework 4.0 and up
Issues in 64 bit VS2022 and Newer
Now that Visual Studio is 64 bit natively, these issues are reversed
IN 64 bit versions of Visual Studio, the Forms Designer will not work properly if you are referencing our x86 DLLs (as one needs to do when platform target is x86)
The fix is to target x64 by changing your application Platform Target to x64 and referencing our x64 DLLs.
Similar to above, the 64 bit version of Visual Studio runs in 64 bit so when it encounters a licenses.licx file while building it works to embed the license by calling the lc.exe process. And for Vs2022 and newer it will use the 64 bit version
We do not have a current KB on how to switch the tool down to x86 for this... In theory you'd follow the basic process outlined above but find the path for the 32 bit (x86) version of lc.exe
However, our suggestion is: if you are dedicated to targeting x86, consider using Visual Studio 2019 or older - it's much easier