Windows Form Designer: Could not load file or assembly - visual-studio

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?

Answer 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.
If you have something like TypeLoadException from Winforms designer, when debugging Visual Studio (devenv.exe process) with another instance of Visual Studio, have a look at the Debug > Modules panel to see exactly which version of your DLL is loaded. Turned out that it was an unexpected version for us, hence the issue.

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

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

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

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

Answer 6

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.

Answer 7

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.
There is no apparent cause for this, just VS bugs.

Answer 8

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.
However, the following resolved the issue: http://support.microsoft.com/kb/967050
Build both the mixed-mode project and the ui project for Win32. Since VS is 32 bit, it cannot load x64 unmanaged code:
Clear the ProjectAssemblies folder (requires shutting down VS first)
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.
Hope this helps someone.

Answer 9

I had this problem in a c++/cli project.
As other people have mentioned, apparently the Windows Form Designer instantiates some version of your Form/Usercontrol before rendering it.
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.

Answer 10

I'm using VS2005 and VS2013 and seen the same problem. Some Visual Studio form designers in my project work and others won't open in design mode. Some opening attempts even crash Visual Studio, before the error page appear, saying:
To prevent possible data loss before loading the designer, the
following errors must be resolved:
An observation:
If there are inherited components in the form, the designer might stop working
A pseudo code example of the observation:
...
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
{
...
}
}
In the non-pseudo-code implementation, I commented out the inherited component MyCtrl in MyForm, and instead used the base class UserControl. The Visual Studio Form Designer started working again!How to write a properly Visual Studio Form Designer -interacting, inherited component class in C# is beyond me. But, this observation might be a clue to someone, whom can work it out.

Answer 11

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.

Answer 12

I've seen this happen in VS2005 for Window Forms, ASP.NET, and Compact Framework projects. The project I'm building has a dependency on another assembly in my solution, but complains that it can't load it when trying to generate the designer file.
I'm not sure on the exact cause, but this sometimes will happen after we bump up the version number of the assembly. For some reason Visual Studio won't see this assembly as "new" and won't drop the new version in the current project's bin/ folder. Most of the time it does though.
Deleting the bin/ folder (and the obj/ folder for good measure) of the project with the designer error, and then rebuilding, seems to make the hurt go away.

Answer 13

I'v faced with the same problem.
I'v removed the reference from the project and added again, and all works fine (looking in the ptoject file i saw that reference definition was changed, for ex. "SpecificVersion" tag was added and set to the "false").

Answer 14

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.

Answer 15

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

Answer 16

I have faced this issue several times. Most of the times clean+rebuild works (sometimes combined with restart of Visual studio).
Two times when clean+rebuild didn't work it was:
Issue #1
In one of the cases that I faced it had to do with C# and VB.NET.
I had several user controls in my Form which was not loading in designer. The user controls were in C#. Most of them were under the same namespace, but few of them had part of the namespace which didn't match in alphabet-case.
For example:
userContorl1 was in myapp.mynamespace1, and
userControl2 was in myapp.myNamespace1
For C# they are different namespaces as C# is case-sensitive. But VB.NET is case-insensitive. The error that I got was when trying to load myapp.mynamespace.userControl2. After struggling for long time, I noticed the namespace in error message and corrected in the user control, making them all same as 'myapp.myNamespace1', and viola designer opened after clean+rebuild.
Issue #2
My Form (which was not opening), had many user controls. One of the control was having a property of enum type. This enum was defined inside a generic class. The designer generated code fo this user control was something like:
myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum
The error that i got while opening designer, was like:
could not load type
somenamespace.SomeGenericClass[System.Date]+SomeEnum
I moved the enum outside the class and replaced the designer code to:
myUserControl1.SomeType = somenamespace.SomeEnum
And the designer opened. :)
I hope this helps somebody.

Answer 17

I will say the responses in this thread helped me somewhat, but didn't exactly nail down what was occurring in my custom user controls.
In my particular case, I have numerous helper class libraries that perform such things as styling on my controls, background logging, and just generic helper classes that perform routine things I do all the time.
I was using some of these other library static methods to perform logging in the case of error. Here's an example:
try
{
_InitializeStuff();
}
catch (Exception ex)
{
Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage);
}
I did this in the Constructor, Load, and Property Set methods of my User Controls ... and the designer couldn't always build it's path to the static method calls, so the designer would fail.
I tried placing DesignMode checks around it, but the problem wasn't at runtime -- it was designtime, and the links couldn't be built. The only option for me was to remove all references to my static helper classes in the following places of my Custom User Controls:
Constructor
Load
Property Accessors
Trying to debug this with a secondary IDE and using Attach to Process did not work for me, unfortunately.

Answer 18

Also make sure you have a using declaration for the library with the control in your form or control. Once the designer knows about it, it write the full namespace in references to objects in the Form.designer.cs file.

Answer 19

I tried many of the suggestions above related to deleting files, rebuliding, restarting, etc. My problem was that it could not load a utility assembly that was used by a few projects in the solution. Another project had common controls. So, Form1 referenced ControlsAssembly1 referenced UtilityAssembly1. The .resx file had properties of types in UtilityAssembly1. I deleted the resources that contained those types. Tried to open the form again (got Null Reference exception because of the missing resource), hit Ignore and Continue and my problem was fixed.

Answer 20

In order to get your From back.
First of all go to Visual studio 2008 command prompt.
type devenv /resetsettings
type devenv /resetSkippkgs
In solution explorer click the "Show All files"
Now Open Form1.vb by double clicking, then click + to expand it.
Open Form1.Designer.vb
you can see both tab in you editor window (IDE).
Now Right Click tab "Form1.vb" and save it
Similarly Right click the tab Form1.vb [Design] and save it also
Re-Build your project.
Restart Visual Studio.

Answer 21

I have faced this problem. I did what is said above but it didn't make any sense. Then I added the assembly to the references. Rebuild the project. Closed the Visual Studio. Then reopen the screen and the designer appeared as normal.
Regards,

Answer 22

Just to Chime in on this. I build a new version of my UserControl whilst my other project was open and referencing it. When I went back to view the designer in the form referencing the user control, it said it couldn't find the .dll of a specific version.
I tried to remove the reference to the control and from the toolbox, with no luck. The code would compile just fine, but the designer wouldn't show without the error.
Tried all the above and it didn't work.
The .res file for the form has some 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>
I removed this from the .res file and all is well. I did backup the whole folder before I tried this though!