【问题标题】:Could not find type 'xxx.xxx.xxx'. Please make sure that the assembly找不到类型“xxx.xxx.xxx”。请确保组装
【发布时间】:2013-09-25 15:42:43
【问题描述】:

我搜索了 StackOverflow 并在尝试打开引用不同项目中的 UserControl 的表单时发现了类似的问题。

我明白了

为防止在加载设计器之前可能丢失数据,必须解决以下错误:

与以下两个错误有关的消息:

找不到类型“MyNamespace.CommonUi.InformationBox”。请做出来 确保引用了包含此类型的程序集。如果这 type 是您的开发项目的一部分,请确保该项目 已使用您当前平台的设置成功构建 或任何 CPU。

变量“InformationBox1”要么未声明,要么从未声明 已分配。

InformationBox1 是设计器中表单上的用户控件InformationBox 的一个实例 - 它只是被引用为;

Friend WithEvents InformationBox1 As MyNamespace.CommonUi.InformationBox

MyNamespace.CommonUi 项目构建成功。

我在项目中获得了智能感知,因此我有理由相信它被正确引用。

到目前为止,和其他人一样:

这是一个从 VS2005 的 .NET2/x86 迁移到 VS2012 的 .NET4/x64 的项目。

现在,当解决方案在 64 位下运行时,它不起作用,我收到了这个设计器错误。但是,如果我将它切换到 32 位(技术上是 AnyCPU),我可以很好地打开设计器。

我已经阅读了类似主题中的其他建议,但他们没有看到提供任何解决方案(我什至已经走到了“左右移动以使其重建”选项)

【问题讨论】:

  • 每当我得到这样的东西时,我都会经历这些步骤,如果你还没有这样做,也许它会有所帮助:1-关闭 IDE 中的所有表单,2-清理解决方案,3-重建解决方案。
  • 不,试过了。几次。据我所知,.designer.vb 代码没有任何问题,重建并没有改变它(尝试前后比较)
  • 清除和重建我的项目对我有用!

标签: .net vb.net visual-studio-2012 visual-studio-designer


【解决方案1】:

快速修复: 我认为问题在于 Visual Studio 是natively 32bit,并且无法对 64 位的某些组件(例如 ListView)进行 GUI 编辑。 例如。在您拥有 ListView 的表单上,您需要将解决方案更改为 32 位以编辑 GUI。

所以简而言之,当你遇到这个问题时:

  1. 将解决方案改为 32bit 或 AnyCPU
  2. 清理并重建解决方案/项目
  3. 打开 GUI 进行编辑
  4. 保存,将解决方案改回 64 位
  5. 清理并重建
  6. 64 位运行

不幸的是,Visual Studio doesn't come in 64bit 目前还没有,因此所有控件都需要在 32 位模式(或 AnyCPU 模式)下设计。

请参阅此问题以供参考。 VS 2010 designer error 'Could not find type XYZ' in Windows7. Works fine in XP

更新修复: 我终于找到了一个合适的解决方案,可以使用 VS GUI 设计编辑器在 64 位环境中加载和编辑我的自定义/32 位控件。请注意,这适用于 Visual Studio 2019,设计的编辑器的架构在 VS 2022 中发生了变化,所以我不确定这是否仍然适用。

基本上,Visual Studio 设计编辑器发生了一些事情,阻止您在 64 位设计环境中编辑自定义/32 位控件。

  1. 您会注意到,当您在 64 位目标环境中加载任何表单时,您的自定义/32 位控件不会显示在设计器 Toolbox 中。这是问题根本原因的一部分;因为您的控件没有出现在toolbox 中,所以当 VS 尝试加载使用该控件(或扩展该控件的类)的表单时,它会抛出错误,找不到类型 'xxx .xxx.xxx'(在工具箱中,是它没有指定的部分)
  2. 控件未显示在工具箱中的原因之一是 Visual Studio NOT当前 项目中的自定义控件加载到工具箱中(或者自动或即使你manually try 强制它)。因此,如果您的自定义 32 位控件在 当前项目 中,则工具箱不会注册它,因此编辑器将无法加载表单。 See reference

这里的解决方案是在同一解决方案中创建一个新项目,并将您的自定义/32 位控件移动到该新项目中的 new 命名空间中。现在 Visual Studio 将能够查看您的控件并将其加载到 Toolbox。这应该会自动发生,您可以选择将属性 [ToolboxBitmapAttribute(true)] 添加到自定义控件上的 public class 定义中。一旦您的自定义控件出现在工具箱中,那么 Visual Studio 设计编辑器在查找程序集和加载表单并允许您在 64 位设计环境中编辑自定义 32 位控件时应该没有问题。

【讨论】:

  • 这对我来说是个问题。他们应该真正修复错误消息,使其显示“确保平台是 x86 或任何 CPU 以进行设计时编辑”
  • 这太丑了。如果您只有 64 位(例如用 C++/CLI 实现的自定义控件)怎么办?
  • lesigh,请接受我的投票,但这感觉很糟糕/愚蠢(虽然有效)
  • 这是个笑话。我们有一个仅 x64 的第 3 方 UI 组件。所以我们不能查看设计师???
  • 这为我解决了这个问题。非常感谢!
【解决方案2】:

我遇到了这个问题。它只发生在一个表单设计器视图中,尽管它能够在运行时编译、启动、显示此表单并在设计器模式下显示其他表单/控件。

这些步骤没有帮助:

  • 清理和重建
  • 重启工作室
  • 删除所有 bin 和 obj 目录
  • 删除和添加引用
  • 否认、愤怒、讨价还价、抑郁、接受

解决方案适合我的情况:

  1. 重命名缺少的类型(例如 InformationBox => InformationBox2)
  2. 刷新设计师(哇,好用!)
  3. 将类型重命名为其初始名称

【讨论】:

  • 唉,重命名的技巧没有奏效。我假设“刷新设计器”意味着关闭并打开设计器窗口?
  • 我现在没有任何可用的 UI 项目,但据我记得上下文菜单中有“刷新”项和/或按 [F5]。
  • 我在包含 wpf 文本框的 Windows 窗体中遇到了同样的问题。删除和添加引用,然后重建项目解决了我的问题。
【解决方案3】:

将任何 CPU 更改为 X86。您的控件是 32 位的,试图在 64 位机器上运行,但找不到 64 位版本的控件。

【讨论】:

  • 我的控件 应该 都是 64 位的,但我认为控件中一定有 某些东西 迫使它以 32 位运行,所以我得到了不匹配在设计时。如果我将我的主应用程序设置为仅以 64 位运行,但将有问题的项目切换到 AnyCPU,它就可以工作,我可以在主应用程序中查看/编辑引用这个其他项目(现在是 anycpu)的表单。我唯一能想到的是它与嵌入式资源有关——用户控件上有一张灯泡的图片。如果做不到这一点,一定是有什么东西鼓励它不以 64 位运行。需要进一步挖掘...
【解决方案4】:

最近我在 VS 2015 中的一个自定义控件 (C#) 遇到了同样的问题。

我通过清理解决方案(构建 -> 清理解决方案)解决了这个问题,然后重新构建了整个解决方案。一切都顺利回来了。

我的项目设置的平台目标已设置为“任何 CPU”,并勾选了“首选 32 位”复选框。不知道为什么会这样。

【讨论】:

  • 我发誓我没有疯,我确实尝试过这个和其他一些东西,然后来到这里阅读这个,再次尝试,现在一切正常。
【解决方案5】:

我有同样的问题,我通过以下方式解决了它:

  1. 在 Visual Studio 中转到解决方案的属性。
  2. 将“平台”更改为“AnyCPU”。
  3. 重建您的解决方案。
  4. 重新启动 Visual Studio。

【讨论】:

    【解决方案6】:

    只需保存您的项目,将其关闭然后重新打开即可。

    【讨论】:

      【解决方案7】:

      我将一个包含多个项目的大型解决方案更改为从 AnyCPU 面向 x64 平台。尝试打开其中一种解决方案表单的设计器,该解决方案表单引用了其他项目之一中的控件并得到与 OP 相同的错误消息。打开包含控件的项目,发现它仍然以 AnyCPU 为目标。尝试了一个小时才能将其保存为 x64,但没有成功。我最终在记事本中打开了 csproj 文件,用 x64 替换了 AnyCPU,一切都开始工作了。希望这可以帮助像我一样沮丧的其他人。

      【讨论】:

        【解决方案8】:

        我最近在 Visual Studio 2013 中使用 VB.Net 使用自定义 WinForm 用户控件时遇到了同样的错误,该控件本身继承了同一项目中的自定义用户控件基类,并采取了一些措施来找出真正的原因是,在我的情况下,基类和子类都没有无参数构造函数(因为在这种情况下这不是有效的场景)。
        为了修复它,我添加了缺少的构造函数,但将其留空(抛出 NotImplementedException 会导致另一个阻止它显示的问题)。它不漂亮,但它有效。

        为了通过此线程问题中列出的错误查看潜在错误,我必须执行以下操作:

        1. 清理整个解决方案
        2. 关闭 Visual Studio
        3. 重新打开 Visual Studio
        4. 重新打开解决方案
        5. 通过在解决方案资源管理器中右键单击它来构建解决方案(不重新构建,这不起作用)
        6. 在设计器模式下查看用户控件,现在会显示实际错误

        添加构造函数后,我不得不再次执行上述步骤才能使其正常工作。

        【讨论】:

          【解决方案9】:

          虽然有很多关于 32 位等的参考,但对我有用的步骤是:

          • 将所有对用户控件的引用,例如,'InformationBox1 as InformationBox' 转换为完全限定的类引用,例如 'MyNamespace.CommonUi.InformationBox',在所有 Designer.vb 文件中。

            • 清洁解决方案

            • 重建解决方案。

          就我而言,这是一个从 VB6 到 VS2008 的迁移项目,两个环境都是 32 位的,在同一台机器上,没有涉及 64 位的迹象。

          【讨论】:

            【解决方案10】:

            这里有一些进一步的信息: the-designer-could-not-be-shown-with-platform-x64

            当您尝试访问设计器时,在 AnyCPU 中运行的分辨率是一种变通方法,对于我们的目的来说就足够了。

            【讨论】:

            • 这个对我有用:虽然我的程序确实需要在 64 位中运行,但如果我使用设计器,请使用“任何 CPU”并关闭“首选 32 位”。不得不关闭并重新打开解决方案。不确定这是否是必要的
            【解决方案11】:

            我认为您应该将 UI 控制在与 64 位项目不同的项目中,并使用任何 CPU 设置运行它。这将有助于不使用 64 版本清理和重建它。

            【讨论】:

              【解决方案12】:

              如果您针对 x64 进行编译,则会发生这种情况,因为 Visual Studio 设计器无法加载 x64 程序集。 Visual Studio 的设计者只能加载 x86 程序集,因为它是一个仅限 3​​2 位的进程!

              1. 您可以更改为 AnyCPU
              2. 为 x86 构建,然后 Visual Studio 设计器能够加载您的程序集以在设计时显示您的控件
              3. 不要使用 x64 程序集进行设计,只能通过批处理或在 Visual Studio 中构建它们,然后切换回 AnyCPU 或 x86

              【讨论】:

                【解决方案13】:

                你可以换成任何CPU:

                Project => properties => Build
                

                平台目标:更改为Any CPU

                清理并重建,重新打开设计文件。

                【讨论】:

                  【解决方案14】:

                  我知道这是一个非常古老的问题/问题。不过,我想有些人应该知道,最新的 VS 2022(预览版)现在是原生 64 位的,并且可以在构建 64 位应用程序时以 x64 设计器模式处理自定义对象。

                  【讨论】:

                  • 请添加更多详细信息以扩展您的答案,例如工作代码或文档引用。
                  【解决方案15】:

                  这里没有什么对我有用。然后,我只是卸载了包含有问题的设计页面的项目重新加载,清理解决方案并重建解决方案。设计师像魔术一样回来了。

                  【讨论】:

                    【解决方案16】:

                    在某个解决方案(即.sln)中,有些东西似乎让设计师感到困惑。我正在使用visualstudio-17.0.4。我收到以下错误:

                    找不到类型“System.Windows.Forms.UserControl”。请确保引用了包含此类型的程序集。如果此类型是您的开发项目的一部分,请确保该项目已使用您当前平台或任何 CPU 的设置成功构建。

                    请注意,有问题的类型是System.Windows.Forms.UserControl,它是框架提供的类型,而不是我的开发项目中的类型。我引用System.Windows.Forms 并针对.net-4.6 和AnyCPU。该项目构建良好,没有任何错误,甚至 IntelliSense 也知道该类型。设计器可能会尝试以不同于 IntelliSense 的方式加载依赖项。但它没有给我足够的信息来找出它失败的原因。

                    所有的正常分辨率都不适合我。但是,我注意到 Designer 有时会加载。经过进一步的实验,我发现如果我在打开解决方案时尝试在没有打开的编辑器窗口的项目中打开 Designer,只要我先尝试在不同的项目中打开 Designer,它就会加载。请注意,仅卸载和重新加载项目或关闭所有窗口而不重新启动 visualstudio 是不够的。如果您遇到与我相同的问题,请严格按照这些步骤操作。

                    1. 在 Visual Studio 中打开您的解决方案。
                    2. 右键单击包含 winforms Designer 文件的项目并选择卸载项目 (L) 或使用菜单操作窗口/关闭所有选项卡 (M-w l) 关闭所有窗口。
                    3. 退出 Visual Studio。
                    4. 在 Visual Studio 中打开您的解决方案。
                    5. 尝试在不同项目中的文件上打开 Designer。它应该无法加载。
                    6. 如果您之前已卸载项目,请右键单击已卸载的项目并选择重新加载项目 (L)。
                    7. 右键单击项目并选择重建。
                    8. 如果您在多个项目上运行了 Rebuild,请务必稍后选择所有项目并选择 Build。
                    9. 双击(输入)该项目中的 winforms Designer 文件。 Designer 应该会成功加载。

                    如果您需要在多个项目中编辑 winforms Designer 文件,您可能需要卸载然后加载/构建多个项目而不是单个项目。

                    此解决方案是临时的。如果在没有先卸载项目容器 winforms Designer 文件的情况下关闭 Visual Studio,您将无法再打开这些 winforms Designer 文件,直到您再次执行该过程。

                    如果您不使用 100% DPI,您可能希望将步骤 3 和 4 替换为以 100% DPI 模式重新启动 Visual Studio。请注意,这些步骤仅在您尚未打开任何 winforms Designer 文件时才有效(100% 提示仅针对您打开的第一个 winforms Designer 文件显示):

                    1. 在另一个项目中,双击一个 winforms Designer 文件。它可能无法加载,但如果这是您在此 Visual Studio 会话中打开的第一个 winforms Designer 文件,您应该会收到提示:

                      主显示屏上的缩放比例设置为 175%。以 100% 缩放重新启动 Visual Studio Help me decide

                    2. 选择“以 100% 缩放比例重新启动 Visual Studio”选项。

                    【讨论】:

                      猜你喜欢
                      • 1970-01-01
                      • 2020-09-08
                      • 2020-06-05
                      • 2015-12-28
                      • 2021-11-15
                      • 1970-01-01
                      • 1970-01-01
                      • 2021-05-15
                      • 1970-01-01
                      相关资源
                      最近更新 更多