无法加载工具箱项目。它将从工具箱中删除答案

【问题标题】：Failed to load toolbox item. It will be removed from the toolbox无法加载工具箱项目。它将从工具箱中删除
【发布时间】：2015-02-02 01:22:54
【问题描述】：

我有一个WinForm 应用程序。我还为此创建了自己的User Control。一切正常。直到今天，当我尝试将它添加回我的程序时收到错误消息（我从未删除它。Visual Studio 删除了它）。

未能加载工具箱项目#UserControlName。将从中删除工具箱。

我的解决方案资源管理器中有它，但在出现此错误后它从我的工具箱中消失了。我还收到警告说：

'#UserControlName' 永远不会分配给，并且将始终拥有它的默认值为 null。

当我查看我的设计器代码时，这是真的。但是我没有对我的设计器代码做任何事情。我的用户控件在那里定义但未实例化。我怎样才能把它放回去？

这与我将构建平台从x32 更改为x64 的事实有关吗？如果是这种情况，我会感到惊讶，因为在更改之后程序运行良好。

【问题讨论】：

标签： c# .net winforms visual-studio user-controls

【解决方案1】：

我在我们的一个应用程序中遇到了同样的问题，但找不到解决方案。所以我手动创建了用户和自定义控件。再次搜索网络后，我终于找到了为什么设计师在这个特定项目上失败了。答案是项目是 64 位的，而 Visual Studio 仍然没有 64 位版本，它仍然是 32 位。因此设计者无法在 64 位应用程序或类库中加载控件。阅读微软关于此的文章。 Visual Studio 网站上有一篇文章，但已被删除。查看 Visual Studio 支持论坛中的答案。

https://social.msdn.microsoft.com/Forums/vstudio/en-US/77e10b58-43cc-4aab-919f-888f14f99571/x64-class-library-of-user-controls?forum=csharpgeneral

【讨论】：

这也是我的问题。我必须将项目设置为 32 位，以便允许加载用户控件。感谢您的提示。
也为我解决了这个问题——这应该是公认的答案
此链接现已失效，遗憾的是没有可用的存档。
天哪！我不得不为我的项目的另一个方面将编译切换到 64 位，并且从未考虑过设计器可能需要 32 位。非常感谢！
对措辞非常糟糕的错误的最佳回答。请注意，在 VS 从工具箱中删除控件后（按字母顺序排列），当您将 Target CPU 从 64 更改为 Any Cpu 时，它可能会将其推到列表的底部。没有什么是容易的。

【解决方案2】：

我最近遇到了同样的问题。由于这个（也不是本网站和互联网上的任何其他答案）实际上帮助了我，我找到了解决它的方法。
只需清理文件并重建解决方案。就这么简单。

【讨论】：

我遇到了同样的问题，^this（清理/重建）对我有用。编辑设计器不起作用，关闭/重新打开 VS 不起作用。我将一个用户控件放在另一个用户控件中。
我清理了所有项目，重新构建，但仍然遇到与 Disasterkid 相同的问题。甚至退出 VS 并在清理和构建之间重新启动它。太好了，这对某人有用，但我想我也必须在我的用户名前加上“灾难”。
我刚刚在 VS 2017 中遇到了类似的问题，清理/重建对我有用。

【解决方案3】：

更改为 AnyCPU 并重建项目。 Visual Studio 在控件为 64 位时存在问题。

【讨论】：

这个问题解决了吗？我所有的项目都是 64 位的！！
在 Vs2019 中仍然存在问题。由于我使用了一个明确不使用 anycpu 编译的库，因此用户控件不是一个选项。

【解决方案4】：

您不必手动插入用户控件。我有同样的情况，这是有原因的。
在我的例子中，它失败了，因为 EXE 程序集通过使用 CLR 支持类型/clr 编译为“混合模式”。通过设置类型 /clr:pure 将其更改为“仅限托管”后，它起作用了。
详情请见my answer here at SO。

【讨论】：

【解决方案5】：

我遇到了同样的问题，但我找到了解决方案：
用鼠标左键单击“Project_Name”并单击“Build”，然后您可以将 UserControl 添加到您的 WinForm。

【讨论】：

【解决方案6】：

在使用一个大型自定义控件（与源代码控制中的先前工作副本相比几乎没有更改）来解决这个问题数小时后，我将所有代码复制到一个新的控件名称和文件中，并且一切正常。

这是为了识别代码的问题行，因为调试器不会合作。复制的控件（以及大量支持代码和模块）运行良好。

所以这些是修复我的原始代码的非常简单的步骤

在解决方案资源管理器中重命名文件（我只是在末尾添加了一个 s）
重建
测试控件现在可以添加到普通表单中
将控件重命名为原来的名称

第 4 步可能对您来说是可选的，但如果您有源代码控制并且它在库中，您会想要这样做。

这将控制权带回到我所有不起作用的表单上（据我所知）。似乎问题在于 VS 以某种方式记住它不喜欢它？

希望这会有所帮助，我希望下次我忘记修复时能找到此消息:)

附：清理、重建和/或重新运行解决方案是解决此问题的旧方法，但这次它只是整个 (DLL) 类中的一个自定义控件。希望这会有所帮助。

【讨论】：

我也这样做了，但我有一个额外的步骤 - 我必须在我的代码中注释掉对该控件的任何引用，然后重建，然后恢复被注释掉的引用。

【解决方案7】：

对我来说，添加 userControl 后，我首先重建应用程序，然后通过转到项目来刷新工具箱上的项目 => 刷新项目工具箱项目

【讨论】：

【解决方案8】：

主要由 32 位/64 位架构引起。在 Visual Studio 2022 之前 VS 内置 32 位，因此无法显示 64 位组件。

解决方案 1：

在配置管理器中创建一个新的解决方案配置，名称为：“Debug_FormDesign”或其他任何名称。
将所有项目的配置设置为上述名称，并将平台设置为“AnyCPU”。
现在打开所有项目一步一步编译设置，选择上面的配置，将编译->目标CPU选项改为AnyCPU。
关闭所有打开的窗口。
清洁溶液。
重启VS。
选择工具栏中的“Debug_FormDesign”配置为活动状态。
重建解决方案。
打开表单设计器 -> 现在应该可以工作了。

完成 GUI 后，您可以轻松切换回默认的“调试”配置。

解决方案 2：

使用 Visual Studio 2022。

【讨论】：

【解决方案9】：

右键单击 - 重建解决方案为我修复了它！

【讨论】：

【解决方案10】：

在这种情况下，您将不得不修改设计器代码。只要您不对设计器代码进行重大更改，就不应破坏任何内容。为了安全起见，重新实例化其他控件实例化的对象（靠近页面顶部）。设计者应填写属性等的空白。

这也应该将控件返回到工具箱。

【讨论】：

是的，我想我也是这样做的。这是一个反复出现的事情。我什么都不碰，然后VS就一直忘记事情。所以我清理了那些用户控件并再次拖动它们，它可以工作......一段时间。
我遇到了类似的问题，我相信解决方法是让 Visual Studio 相信 .Designer 文件没有被手动编辑。要模拟这一点，您需要确保在 .Designer 文件中声明和实例化控件的顺序相同。这就是为我解决的问题。
这个答案不清楚。究竟如何处理设计器代码？我假设您指的是名为 MyWonderfulControl.designer.cs 的源文件。
这可能是一种绕过可视化编辑器的方法，但不是解决问题的方法！我投了反对票，因为对于各种情况都有一些真正的解决方案，这不应该是公认的答案。

【解决方案11】：

如果有该类型的遗留属性，请检查您的 form.designer 文件。它发生在我身上好几次。在我删除那条线并重建项目后，一切都开始工作了。

【讨论】：

【解决方案12】：

在我的例子中，它有助于在要使用这些控件的表单顶部手动包含创建的用户控件的头文件。

【讨论】：