50

有没有人遇到过尝试在 Visual Studio .NET 中的 Windows 窗体上“查看设计器”导致错误:“无法加载文件或程序集......”

在这种情况下,有问题的程序集是XYZ.dll。我设法通过添加XYZ.dll及其对我项目引用的所有引用(即使我的项目不直接依赖于它们)并重建整个解决方案来解决此问题。然而,在那之后,我从我的项目中删除了所有这些引用,重新构建,它仍然有效。

另一条信息是我使用Resharper 2.5。其他人指出,可能是 Resharper 做了一些影子复制。下次发生这种情况时,我会调查一下。有没有人了解为什么首先会发生此错误,以及可能的“正确”修复方法?

4

22 回答 22

32

我们有同样的问题。某些 Form/UserControl 类无法在设计器中查看,Visual Studio 会导致各种异常。

有一个典型的原因:在初始化期间(在构造函数中或在 Load 事件中或之前)中,设计的组件之一引发了未处理的异常。

不仅在这种情况下,您还可以运行另一个 Visual Studio 实例,打开/创建一些独立项目,转到菜单 -> 调试 -> 附加到进程 ... -> 使用有问题的设计器选择 devenv.exe 进程的实例。然后按Ctrl+Alt+E,应显示“例外”窗口。在异常类别中检查“抛出”。

现在与设计师一起激活视觉工作室并尝试查看设计师。如果将抛出异常,您将看到调用堆栈(可能还有源代码,如果从您的代码中抛出异常)和其他有关抛出异常的典型信息。这些信息可能非常有用。

于 2008-10-03T13:32:26.037 回答
27

这是一个似乎仍然没有答案的老问题,无论是在这里还是在更广泛的论坛池中,大多数建议都与无情的清理>重建或关闭>清理文件夹>重新打开或重新启动机器有关。我目前还没有一个可靠的答案,尽管已经对此进行了一些研究,并认为我可以分享。总而言之,当设计控件或表单时,所有设计器文件都复制到一个位置,旧文件可以存在的另一个位置,并且描述了在设计器生成错误页面之前捕获所有设计器异常的方法。

似乎有两种情况,无法加载或找不到程序集。第一个是由于文件无法复制到设计人员要求的位置,第二个是遗留的过时文件。

如上所述,当项目无法直接引用其引用的引用及其引用所需的所有引用时,文件可能无法复制,递归地向下到框架。这可以通过仔细跟踪所有参考及其家属来缓解,确保所有参考都得到考虑。

Visual Studio 设计器使用特定位置缓存 dll 以供其在设计器中使用,与项目的源 /bin 文件夹隔离:

视窗XP:

C:\Documents and Settings\[用户名]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies

Windows 7的:

C:\Users\[用户名]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

在此位置,已编译的程序集被复制到动态创建的文件夹中,每个程序集一个文件夹。检查此位置上的程序集版本日期,它似乎是最新的,在 Visual Studio 退出时被删除。当使用新编译的文件查看设计器时,会复制所有程序集。为每个设计者将每个组件的新副本制作到此位置,因此该位置可以保存每个组件的多个相同副本。

然而,存在另一个位置可以复制程序集,并且是程序集搜索序列的一部分,显然在 ProjectAssemblies 文件夹之前,并且位于:

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

我不知道程序集如何或何时复制到此位置,但这种情况并不常见,因此到达此处的文件很快就会成为过时引用的来源。当设计者因“加载文件或程序集失败”错误而失败时,设计者寻求的版本是仅由该位置的程序集引用的版本。

这是通过在第一个上使用第二个 Visual Studio 实例调试发现的,加载了所有 .net 符号,并且所有已知的异常都在抛出时中断,而不是在未处理时中断。这允许第二个实例拦截已处理的设计器异常并显示该文件位置。这是我使用的设计器错误的结果输出:

=== Pre-bind state information ===
LOG: User = **************
LOG: DisplayName = ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/
LOG: Initial PrivatePath = NULL
Calling assembly : ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
于 2011-10-21T19:59:24.247 回答
13

删除解决方案中所有项目的所有 bin 和 obj 目录。同时删除 C:\Users<User>\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies 中的文件夹。VS2008 使用 9.0,VS2010 使用 10.0 等。

于 2013-02-15T04:18:54.357 回答
8

在这个问题上挣扎了几个小时。以下是我学到的:检查 DLL THE DESIGNER 尝试加载的是否为 64 位 DLL

事实证明,现在对我来说很明显,VS 是一个 32 位应用程序,因此 VS 设计器——惊喜!惊喜!也是一个 32 位应用程序,所以如果你有一个 UserControl 或其他 WinForms 控件引用了一个 64 位 DLL -这是一个很大的 NO-NO,这将导致你的表单不在 VS Designer 中呈现并生成无法加载文件或程序集错误。所以你应该做的第一件事是确保设计者抱怨的 DLL不是64 位 DLL。

于 2016-06-29T19:16:24.660 回答
5

使用 VS 2005,我遇到了同样的问题。我执行了 Chien 在他原来的问题中列出的步骤,但是直到我关闭 VS 并重新打开解决方案之前它仍然没有用。现在设计器视图看起来不错。

于 2009-01-12T21:35:58.910 回答
3

我想这个问题的发生有不同的原因,但我想我还是会分享我的案例。我希望有人能找到他们项目进展的线索。

我的问题是因为 Visual Studio(C# 项目)找不到托管的 c++ dll 并将其复制到 J Collins 帖子中提到的位置 => 设计器找不到文件。我注意到它没有与其他 DLL:s 一起复制到那里,并发现它有一个不同/非标准的输出目录。将此更改为标准使 Visual Studio 执行复制。

于 2012-11-23T07:00:14.587 回答
2

我在 VS2005 上经常遇到这种情况,特别是在向 winform 添加自定义控件时。通常我只需要重建,不需要添加额外的引用,或者关闭并重新打开 VS。

没有明显的原因,只有 VS 错误。

于 2008-10-03T13:27:24.110 回答
2

我有一个类似的问题。

就我而言,我有一个基本表单,它引用了混合模式 dll 中的一个类(c++ 托管包装器到非托管库)。我的派生表单没有正确加载,出现上述相同的错误。

但是,以下解决了该问题:http: //support.microsoft.com/kb/967050

  1. 为 Win32 构建混合模式项目和 ui 项目。由于 VS 是 32 位的,它无法加载 x64 非托管代码:
  2. 清除 ProjectAssemblies 文件夹(需要先关闭 VS)

当您重新打开 VS 时,设计器加载没有问题。请注意,默认情况下,C# 项目编译为在 Windows x64 上编译为 x64 的任何 CPU。

希望这可以帮助某人。

于 2013-04-03T15:24:45.787 回答
1

我在 c++/cli 项目中遇到了这个问题。

正如其他人所提到的,显然 Windows 窗体设计器在呈现之前实例化了您的窗体/用户控件的某个版本。

如果表单设计器由于某种原因无法实例化该类,它将失败。所以我所做的就是注释掉有问题的用户控件的构造函数,并重建我的项目。

这让我可以再次使用表单设计器。

当然,您可以使用此方法选择性地注释掉构造函数的某些部分,直到识别出使表单设计器阻塞的部分,并在可能的情况下对其进行修复。

于 2013-04-04T19:51:38.607 回答
1

我正在使用 VS2005 和 VS2013 并看到同样的问题。我的项目工作中的一些 Visual Studio 表单设计器和其他的不会在设计模式下打开。在错误页面出现之前,一些打开尝试甚至使 Visual Studio 崩溃,并说:

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

一个观察:
如果表单中有继承的组件,设计者可能会停止工作

观察的伪代码示例:

...
using System.Windows.Forms; // UserControl

namespace MyNamespace
{
    public class MyForm : Form
    {
        public MyForm()
        {
            InitializeComponent();
            ...
        }

        private void InitializeComponent()
        {
            //this.ctrl = new MyNamespace.MyCtrl(); // Inherited class
            this.ctrl = new System.Windows.Forms.UserControl();
            ...
        }

        //private MyNamespace.MyCtrl myCtrl;        // Inherited class
        private UserControl ctrl;
    }

    public class MyCtrl : UserControl
    {
        ...
    }
}

在非伪代码实现中,我把继承的组件注释掉了MyCtrlMyForm改用基类UserControlVisual Studio 表单设计器再次开始工作!

如何在 C# 中编写一个正确的Visual Studio Form Designer -interacting、继承组件类超出了我的范围。但是,这个观察结果可能是一个线索,有人可以解决这个问题。

于 2016-09-01T06:54:19.937 回答
0

I have found, with problems like this, and many others, the problem tends revolve around the .NET framework installation. Lots of times, like during a system crash, files can become corrupted esp. if you have virtual memory turned off. When files in the C:\WINDOWS\Microsoft.NET folder get corrupted, they don't work the way they should, since there are alot of these files, errors dont always happen. Some parts of a file might be ok and load, then others dont. Over the years I have found keeping a FULL backup of the Microsoft.NET folder in an archive that has some type of corruption protection works well for me. You would not believe the number of things that corrupted .NET files cause to go wrong. Just about every aspect of the IDE depends on parts of it as well as many other features. Of course, if you dont have a backup you should UNINSTALL ALL NET FRAMEWORK INSTALLATIONS (don't repair because this does not guarentee files being rewritten -- the files might pass checksum and length checks but still be corrupt). After uninstalling, reboot the system, ensure that the entire Microsoft.NET folder is deleted, if not, delete it yourself (I had to do this, some files still get left behind). Once this is done, reinstall the NET framework, depending on your OS, you might not be able to get rid of the whole thing. But with windows XP I know you can, i havent tested this on newer OSes youre on your own for that one as far as testing goes. I started out by installing 2.0, then 3.5 SP1, and so on, depending on which Visual Studio you are using. I stick with 2008 because its the fastest for me and still has support for some of the newer stuff like WPF, tr1, etc... hope this helps you an anyone else with .NET woes, the error messages are often misleading but for me 99% of the time it is Microsoft.NET file corruption.

于 2013-01-11T17:32:14.193 回答
0

I concur with the Resharper comment. I'm running 4.1. I disabled it, restart VS2008, and tried the "Convert to Web Application" again, and it worked.

于 2009-02-12T15:17:57.697 回答
0

我遇到了同样的问题。我从项目中删除了引用并再次添加,一切正常(查看 ptoject 文件,我看到引用定义已更改,例如,添加了“SpecificVersion”标签并设置为“false”)。

于 2011-10-24T12:47:00.610 回答
0

我在 VS2005 的 Window Forms、ASP.NET 和 Compact Framework 项目中看到了这种情况。我正在构建的项目依赖于我的解决方案中的另一个程序集,但抱怨它在尝试生成设计器文件时无法加载它。

我不确定确切的原因,但这有时会在我们提高程序集的版本号后发生。由于某种原因,Visual Studio 不会将此程序集视为“新”,并且不会将新版本放入当前项目的 bin/ 文件夹中。大多数时候它确实如此。

删除带有设计器错误的项目的 bin/ 文件夹(以及 obj/ 文件夹),然后重新构建,似乎可以让伤害消失。

于 2009-08-20T23:19:47.050 回答
0

对于将来遇到此问题并一直向下滚动搜索的任何人:Delete ComponentModelCache in Appdata/Local/Microsoft/VisualStudio/..

于 2015-06-05T21:33:20.813 回答
0

为了让你的From回来。首先转到 Visual Studio 2008 命令提示符。

类型devenv /resetsettings
类型devenv /resetSkippkgs

  1. 在解决方案资源管理器中单击“显示所有文件”
  2. 现在通过双击打开 Form1.vb,然后单击 + 将其展开。
  3. 打开 Form1.Designer.vb
  4. 您可以在编辑器窗口 (IDE) 中看到这两个选项卡。
  5. 现在右键单击选项卡“Form1.vb”并保存
  6. 同样右键单击选项卡 Form1.vb [Design] 并保存它
  7. 重新构建您的项目。
  8. 重新启动 Visual Studio。
于 2017-08-25T07:20:38.043 回答
0

我已经多次遇到这个问题。大多数时候都clean+rebuild有效(有时与 Visual Studio 的重新启动相结合)。

两次clean+rebuild没有工作是:

问题 #1

在我遇到的一种情况下,它与 C# 和 VB.NET 有关。

我的表单中有几个用户控件没有加载到设计器中。用户控件在 C# 中。它们中的大多数都在同一个命名空间下,但很少有部分命名空间的字母大小写不匹配。

例如:

userContorl1 was in myapp.mynamespace1, and 
userControl2 was in myapp.myNamespace1

对于 C#,它们是不同的命名空间,因为 C# 区分大小写。但是 VB.NET 不区分大小写。我得到的错误是在尝试加载 myapp.mynamespace.userControl2 时。苦苦挣扎了半天,发现报错信息中的命名空间,在用户控件中更正,使它们都和'myapp.myNamespace1'一样,中提琴设计器在clean+rebuild.

问题 #2

我的表单(未打开)有很多用户控件。其中一个控件具有枚举类型的属性。这个枚举是在一个泛型类中定义的。设计器为此用户控件生成的代码类似于:

myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum

我在打开设计师时遇到的错误是:

无法加载类型 somenamespace.SomeGenericClass[System.Date]+SomeEnum

我将枚举移到了课堂之外,并将设计器代码替换为:

myUserControl1.SomeType = somenamespace.SomeEnum

设计师打开了。:)

我希望这对某人有所帮助。

于 2016-03-10T11:12:08.327 回答
0

我尝试了上述许多与删除文件、重新构建、重新启动等有关的建议。我的问题是它无法加载解决方案中一些项目使用的实用程序程序集。另一个项目有共同的控制。因此,Form1 引用了 ControlsAssembly1 引用了 UtilityAssembly1。.resx 文件具有 UtilityAssembly1 中类型的属性。我删除了包含这些类型的资源。尝试再次打开表单(由于缺少资源而出现空引用异常),点击忽略并继续,我的问题得到了解决。

于 2017-06-25T17:52:46.823 回答
0

我遇到过这个问题。我做了上面所说的,但没有任何意义。然后我将程序集添加到引用中。重建项目。关闭了 Visual Studio。然后重新打开屏幕,设计器正常出现。

问候,

于 2018-03-29T08:05:36.327 回答
0

只是为了插话。当我的其他项目打开并引用它时,我构建了我的 UserControl 的新版本。当我回去查看引用用户控件的表单中的设计器时,它说它找不到特定版本的.dll。

我试图从工具箱中删除对控件的引用,但没有成功。代码可以编译得很好,但设计者不会在没有错误的情况下显示。

以上方法都试过了,还是不行。

表单的 .res 文件有一些 XML:

<data name="EventBar1.EventCheckedSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>
  <data name="EventBar1.EventLengthSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>
  <data name="EventBar1.EventLengthTypes" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAKABY3RybENhbGVuZGFyU2lkZUJhciwgVmVyc2lvbj0xLjAuNzEy
        MS4yMTIzNCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1udWxsXV0sIG1zY29ybGliLCBW
        ZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0
        ZTA4OQwDAAAAUWN0cmxDYWxlbmRhclNpZGVCYXIsIFZlcnNpb249MS4wLjcxMjEuMjEyMzQsIEN1bHR1
        cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAT1N5c3RlbS5Db2xsZWN0aW9ucy5HZW5l
        cmljLkxpc3RgMVtbY3RybENhbGVuZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAA
        Bl9pdGVtcwVfc2l6ZQhfdmVyc2lvbgQAAC5jdHJsQ2FsZW5kYXJTaWRlQmFyLkV2ZW50QmFyK0V2ZW50
        TGVuZ3RoVHlwZVtdAwAAAAgIAgAAAAkEAAAAAAAAAAAAAAAHBAAAAAABAAAAAAAAAAQsY3RybENhbGVu
        ZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAACw==
</value>
  </data>
  <data name="EventBar1.EventSettingsSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>

我从 .res 文件中删除了它,一切都很好。在我尝试这个之前,我确实备份了整个文件夹!

于 2019-07-01T14:29:09.307 回答
0

我会说这个线程中的回复对我有所帮助,但并没有完全确定我的自定义用户控件中发生的事情。

在我的特殊情况下,我有许多帮助类库来执行诸如在我的控件上设置样式、后台日志记录以及执行我一直在做的例行事情的通用帮助类。

在出现错误的情况下,我正在使用其中一些其他库静态方法来执行日志记录。这是一个例子:

try { _InitializeStuff(); } catch (Exception ex) { Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage); }

我在我的用户控件的构造函数、加载和属性集方法中做到了这一点......设计者不能总是建立它的静​​态方法调用的路径,所以设计者会失败。

我尝试在它周围放置 DesignMode 检查,但问题不在运行时 - 它是设计时,并且无法构建链接。我唯一的选择是在我的自定义用户控件的以下位置删除对我的静态帮助程序类的所有引用:

  • 构造函数
  • 加载
  • 属性访问器

不幸的是,尝试使用辅助 IDE 进行调试并使用 Attach to Process对我不起作用

于 2016-03-31T18:24:59.170 回答
0

还要确保您在表单或控件中具有使用控件的库的using声明。一旦设计者知道它,它就会在 Form.designer.cs 文件中的对象引用中写入完整的命名空间。

于 2016-07-01T15:17:02.287 回答