又是最近遇到的一个所谓的玄学问题。看样子最近重新开始写代码之后遇到的玄学问题比较多。（笑）
惯例，上来先介绍问题背景。
开发环境：
OS：Win10；
IDE：Visual Studio 2017；
第三方控件： DevExpressNETComponents
最近由于种种原因吧，你也可以认为是我闲的蛋疼，我把我们项目的编译平台目标从Any CPU变更成了x64。然后一顿修改引用的第三方库等等，能够成功编译、运行。然后我打开主界面窗体的设计器，直接懵逼。各种错误，当头第一个就是下面列出的错误。
未能找到类型“xxx.WinApplication.RibbonControlFullScreen”。请确保已引用包含此类型的程序集。如果此类型为开发项目的一部分，请确保已使用针对当前平台或任意 CPU 的设置成功生成该项目。
解决过程及思路：
这个问题我之前遇到过，确实和切换编译的平台目标有关，但是之前都是再切换成Any CPU了事。没有深究其原因。恰好这次我也不想切换平台目标了，打算研究一下为什么会这样。首先能够成功编译以及运行。那么证明从代码和体系角度说，切换平台目标是没有任何问题的，那为什么偏偏设计器报错呢？我又挨个点了所有窗体、用户自定义控件（下文将两者统称界面）的设计器。发现一个规律，只要是没有引用、继承其它界面的界面，都能够在设计器打开，展示。引用、继承了其它界面的界面，设计器都会报错。这是一个很重要的信息。然后我新建了一个测试界面，通过设计器拖动的方式随意引用了一个用户自定义控件，果不其然，直接报错。
未能加载工具箱项“某UserControl”。将从工具箱中将其删除。
问题找到了，这就是IDE的锅！众所周知，巨硬在宇宙第一IDE，Visual Studio项目上，直到2022年才决定推出64位（x64）版本，还是个预览版！那么Visual Studio 2017自然本身就是个32位（x86）的程序，它的工具箱自然无法加载项目编译好的64位（x64）的动态链接库，它的设计器自然也会报错了。巨硬请主动把锅接好。
既然问题找到原因了，那么解决思路也很简单了，分为两种情况：
- 可以切换平台目标。这种情况下，非常简单。将UserControl所在的项目的编译平台目标从x64切换成Any CPU重新编译即可。但是注意：此时，如果你的项目是x86的，那么编译出来的动态链接库是32位（x86）的。
- 不可以切换平台目标。这种情况就比较费劲，你只能放弃VS自带的工具箱和设计器界面。通过手撸加载UserControl。或者，使用Visual Studio 2022 Preview或以上的版本重新打开编译你的项目。
延伸：
32位和64位的兼容性问题。这个问题是老生常谈的问题了。从程序角度说，32位程序基本上可以在64位的PC上运行，64位的程序无法在32位的PC上运行。基于这个情况，当你的程序中有一个32位的引用或项目的时候，如果你选择了Any CPU，VS都会将你的项目编译成32位的程序。VS里甚至有个32位优先的生成选项供用户勾选。怎么使用，见仁见智了。是要更好的兼容性还是更优的性能，选择权在你手中。