visual-studio Windows 窗体设计器：无法加载文件或程序集

Windows Form Designer: Could not load file or assembly

提问by

Has anyone ever had the issue where trying to "View Designer" on a windows form in Visual Studio .NET causes the error: "Could not load file or assembly…"?

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

In this case, the assembly in question was XYZ.dll. I managed to fix this by adding XYZ.dlland all its references to my project's references (even though my project doesn't directly depend on them) and rebuilding the whole solution. However, after that, I removed all those references from my project, rebuilt, and it still worked.

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

One other piece of information is that I use Resharper 2.5. Someone else pointed out that it might be Resharper doing some shadow copying. I'll look into this next time this happens. Does anyone have a understanding of why this error happens in the first place, and possibly the 'correct' way to fix it?

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

回答by TcKs

We have same problem. Some Form/UserControl classes can not be viewed in designer and Visual Studio causes various exceptions.

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

There are one typical cause: One of designed component thrown unhandled exception during initialization ( in constructor or in Load event or before ).

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

Not only for this case, you can run another instance of visual studio, open/create some independent project, go to menu -> Debug -> Attach to process ... -> select instance of devenv.exe process with problematic designer. Then press Ctrl+Alt+E, the "Exceptions" windows should be shown. There check "Thrown" in categories of exception.

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

Now active the visual studio with designer and try view designer. If the exception will be thrown, you will see callstack ( and maybe source code, if the exception was thrown from your code ) and other typical information about thrown exception. This information may be very helpful.

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

回答by J Collins

This is an old question that still appears to have no answer, either here or in the wider forum pool, most advice relates to relentless clean>rebuilds or close>clean folders>reopen or restarting the machine. I don't have a solid answer at present though have done some research into it and thought I might share. Summarily, there is one location into which all designer files are copied when a control or form is designed, another location which old files can exist and a method is described to catch all designer exceptions before the designer can generate the error page.

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

There appears to be two cases where either an assembly cant be loaded or can't be found. The first is caused by files failing to copy to designer-required locations, the second is outdated files being left behind.

似乎有两种情况，要么无法加载程序集，要么无法找到程序集。第一个原因是文件未能复制到设计人员要求的位置，第二个原因是遗留的过时文件。

As mentioned above files can fail to copy when a project fails to directly reference all references required by its referenced references and their references, recursively, down to the framework. This can be alleviated by carefully tracking all references and their dependents, ensuring all are accounted for.

如上所述，当项目无法直接引用其引用的引用及其引用所需的所有引用时，文件可能无法复制，递归地直到框架。这可以通过仔细跟踪所有引用及其依赖项来缓解，确保所有引用都被考虑在内。

The Visual Studio designer uses a specific location to cache dlls for its use in the designer, isolated from the source /bin folders of the projects:

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

Windows XP:

视窗 XP：

C:\Documents and Settings\[user_name]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies

C:\Documents and Settings\[user_name]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies

Windows 7:

Windows 7的：

C:\Users\[user_name]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

C:\Users\[user_name]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

In this location, compiled assemblies are copied to dynamicallycreated folders, one folder per assembly. Checking the assembly version dates on this location, it seems to be quite up to date, being deleted when visual studio exits. All assemblies are copied when a designer is viewed with newly compiled files. A new copy of each assembly is made into this location for each designer, so the location may hold multiple identical copies of each assembly.

在此位置，编译的程序集被复制到动态创建的文件夹中，每个程序集一个文件夹。检查这个位置的程序集版本日期，它似乎是最新的，在visual studio退出时被删除。当使用新编译的文件查看设计器时，所有程序集都会被复制。对于每个设计者，每个组件的新副本都被制作到此位置，因此该位置可能包含每个组件的多个相同副本。

One other location exists however where assemblies may be copied, and is a part of the assembly search sequence, apparently ahead of the ProjectAssemblies folder and that is in:

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

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

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

I have no knowledge of how or when assemblies get copied to this location, but it is not often so what files do arrive here quickly become a source of outdated references. When a designer failed with the 'Failed to load file or assembly'error, the version sought by the designer was a version only referenced by the assembly at this location.

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

This was discovered by using a second Visual Studio instance debugging on the first, with all .net symbols loaded, and all known exceptions breaking on throw as opposed to when unhandled. This allowed the second instance to intercept the handled designer exceptions and reveal that file location. This was the resulting output of the designer error that I used:

这是通过在第一个上使用第二个 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.

回答by Raymond Holmboe

What helped for me was deleting ALL bin and obj directories for all the projects in the solution. Also delete the folders in C:\Users\\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies as previously mentioned. Use 9.0 for VS2008, 10.0 for VS2010 etc.

对我有帮助的是删除解决方案中所有项目的所有 bin 和 obj 目录。如前所述，还要删除 C:\Users\\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies 中的文件夹。VS2008 使用 9.0，VS2010 使用 10.0 等。

回答by Dean Hill

Using VS 2005, I ran into this same problem. I performed the steps Chien listed in his original question, but it still didn't work until I closed VS and reopened the solution. Now the Designer view looks fine.

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

回答by Denis

Was struggling with this issue for a few hours. Here's what I learned: CHECK IF THE DLL THE DESIGNER IS TRYING TO LOAD IS A 64-BIT DLL.

在这个问题上挣扎了几个小时。这是我学到的：检查设计者试图加载的 DLL 是否为 64 位 DLL。

Turns out, well, obvious to me now, VS is a 32-bit application, therefore the VS Designer -- surprise! surprise! is also a 32-bit application so if you have a UserControl or other WinForms control that has a reference to a 64-BIT DLL -- THAT IS A BIG NO-NO which will cause your form not to render in the VS Designer and produce the could-not-load-file-or-assembly error. So the first thing you should do is make sure that the DLL the Designer is complaining about is NOTa 64-bit DLL.

结果，嗯，现在对我来说很明显，VS 是一个 32 位应用程序，因此 VS 设计器 - 令人惊讶！惊喜！也是一个 32 位应用程序，所以如果你有一个 UserControl 或其他 WinForms 控件，它有一个 64 位 DLL 的引用——这是一个很大的禁忌，它会导致你的表单不在 VS 设计器中呈现并产生无法加载文件或程序集错误。因此，您应该做的第一件事是确保设计者抱怨的 DLL不是64 位 DLL。

回答by SolSken

I guess this problem occurs for different reasons, but I thought I'd share my case anyway. I hope someone will find a clue to what's going on with their project.

我想这个问题的发生有不同的原因，但我想无论如何我都会分享我的案例。我希望有人能找到有关他们项目进展情况的线索。

My problem occured since Visual Studio (C# project) couldn't find the managed c++ dll and copy it to the location mentioned in J Collins post => the designer couldn't find the file. I noticed it wasn't copied there with the other DLL:s and found out that it had a different/non-standard output directory. Changing this to the standard made Visual Studio perform the copy.

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

回答by Mahen

I had a similar problem.

我有一个类似的问题。

In my case, I had a base form, which referenced a class in a mixed-mode dll (c++ managed wrapper to unmanaged library). My derived form did not load correctly, giving the same error described above.

就我而言，我有一个基本形式，它引用了混合模式 dll 中的一个类（c++ 托管包装器到非托管库）。我的派生形式没有正确加载，给出了与上述相同的错误。

However, the following resolved the issue: http://support.microsoft.com/kb/967050

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

1. Build both the mixed-mode project and the ui project for Win32. Since VS is 32 bit, it cannot load x64 unmanaged code:
2. Clear the ProjectAssemblies folder (requires shutting down VS first)

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

When you reopen VS, the designer loads with no issues. Note that by default, C# projects are compiled as Any CPU which compiles to x64 on Windows x64.

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

Hope this helps someone.

希望这可以帮助某人。

回答by Santiago Palladino

It happened to me very frequently on VS2005, specially when adding custom controls to the winform. Usually I just needed to just rebuild, without needing to add extra references, or close and reopen VS.

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

There is no apparent cause for this, just VS bugs.

这没有明显的原因，只是 VS 错误。

回答by IJC

I had this problem in a c++/cli project.

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

As other people have mentioned, apparently the Windows Form Designer instantiates some version of your Form/Usercontrol before rendering it.

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

If the Form Designer cannot instantiate the class for whatever reason, it will fail. So what I did was comment out the constructor of the offending Usercontrol, and rebuild my project.

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

This allowed me to use the Form Designer again.

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

Of course you could use this method to selectively comment out parts of the constructor until identifying the part that makes the Form Designer choke, and if possible fix it.

当然，您可以使用此方法有选择地注释掉构造函数的某些部分，直到识别出使 Form Designer 窒息的部分，并在可能的情况下修复它。

回答by Hele

To anyone who has this problem in the future and scrolled all the way down searching for it : Delete ComponentModelCache in Appdata/Local/Microsoft/VisualStudio/..

对于将来遇到此问题并一直向下滚动搜索的任何人：在 Appdata/Local/Microsoft/VisualStudio/.. 中删除 ComponentModelCache。