WinForm下的UserControl编译问题

28 0

又是最近遇到的一个所谓的玄学问题。看样子最近重新开始写代码之后遇到的玄学问题比较多。(笑)

惯例,上来先介绍问题背景。

开发环境:

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位优先的生成选项供用户勾选。怎么使用,见仁见智了。是要更好的兼容性还是更优的性能,选择权在你手中。