Windows Form Designer: Could not load file or assembly

Question

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…" ?

In this case, the assembly in question was XYZ.dll. I managed to fix this by adding XYZ.dll and 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.

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?

Solution 1

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

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

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.

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.

Solution 2

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:

Windows XP:

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

Windows 7:

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

In this location, compiled assemblies are copied to dynamically created 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.

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:

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:

=== 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.

Solution 3

Delete ALL bin and obj directories for all the projects in the solution. Also delete the folders in C:\Users<User>\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies. Use 9.0 for VS2008, 10.0 for VS2010 etc.

Solution 4

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.

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 NOT a 64-bit DLL.

Solution 5

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.

View more solutions

Comments

[Admin]

Thanks! This sounds like something I would definitely try the next time I get hit by this. I would like to point out though that I have always been open to this form. It just happened recently.

[jcollum]

Used to happen to me all the time with Infragistics Winforms controls. Freakin annoying, and it only happened on my machine, even though there were 5 people using the exact same code.

[KeithS]

This was my answer as well. I had a direct dependency (a project of interfaces) that the designer couldn't find, but the solution compiled just fine. Restarting VS did the trick.

[razlebe]

This would be better as an edit on the question, rather than posted as an answer.

[J Collins]

True it isn't an answer, though it's not really a question either. Perhaps stackoverflow et al needs a 'discussion' section on questions where contributors can collectively work toward a solution?

[jpa]

Thanks, clearing out the folder under AppData fixed the problem for me.

[gawicks]

Extremely useful. Thanks!

[Mo Patel]

An old post but this has just saved me a lot of head scratching! Thanks buddy :).

[Mike B]

This was very helpful!! Thanks!

[vaheeds]

WOW! with your solution, I could find the exact line of the code in an unexpected project under the hood, that causes the error, that never thought that it can be a problem.

[ToolmakerSteve]

Re "I tried placing DesignMode checks around it, but the problem wasn't at runtime -- it was designtime..." To NOT execute code at design time do: if not DesignMode .... - if that wasn't helping you, then you probably encountered DesignMode with nested Controls. How to fix: This test always works, or This is a cached version of that test.

[rgoliveira]

The answers above didn't work, but this one did it. Recompiled my solution as x86 and was able to open the designer.

[xvan]

Had the inverse problem in VS 2022 (which is 64bit). Designer crashes trying to load a 32 bit tlbimp dll.