views:

266

answers:

3

We're experiencing several cases where on loading up a project that was otherwise OK, gives an error in the Winforms designer along the lines of:

Could not load file or assembly 'MyLibrary, Version=1.4.3419.14461, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

And Visual Studio dies, prompting us if we wish to send debug information to Microsoft -- if this prompt is ignored, we are able to close the affected tabs, save all, and all is fine on a reload; if we don't close the affected tabs, the problem repeats.

I'm unsure if this is a Visual Studio bug, or we're doing something "wrong" or unexpected. Has anyone any ideas on where to look, or common causes of this sort of issue?

(For the sake of argument, the solution consists of MyLibrary and MyLibrary.Windows, which has a project reference to the former. Both projects build with no issues once Visual Studio loads. If it makes any difference, the projects have been migrated from VS2003, which in turn didn't exhibit this crash)

EDIT:

Have also tried loading the solution with a debugger attached, with the solution loaded, and it crashes out without stopping on any exceptions

A: 

You can try:

  • Clean the solution and do full rebuild
  • Delete the offending references and add them again
  • Clean the solution and perform a full rebuild again
  • Restart Visual Studio

Good luck

Edit:

Also try to set the referenced dll specific version to false and reload the solution. See http://channel9.msdn.com/forums/TechOff/261335-Dreadful-Visual-Studio-2008-crash-Solved/?CommentID=392089

amartin
Strictly speaking, those options aren't available -- VS has crashed on loading the solution; only way around is to close the offending tab, save all (to save the suo file) or else delete the suo file altogether, and then the solution will load and work fine in a new Visual Studio session. It only seems to occur when a form that is checked out with a user control on it is in design mode when closing Visual Studio...
Rowland Shaw
Try to set the specific version property on the referenced MyLibrary on MyLibrary.Window references to false. Maybe the assembly version got mixed up, save all and reload the solution. More info here: http://channel9.msdn.com/forums/TechOff/261335-Dreadful-Visual-Studio-2008-crash-Solved/?CommentID=392089
amartin
A: 

Do you have a control that makes an assumption about its parent form? When the forms designer loads your form, it creates instances of your controls, but not an instance of your form class.

So if one of your controls relies on only ever being instantiated with your form class as its parent, it could crash when loaded into the form designer.

RichieHindle
The controls don't explicitly refer to the form they're on (no more than any control that inherits from `System.Windows.Forms.UserControl`)
Rowland Shaw
+1  A: 

I've seen crashes of this sort before, caused by exposing public properties on a custom user control that weren't simple types or structs already supported by the visual studio designer.

For example (code written off the cuff to illustrate):

public class MyUserControl : UserControl
{
    // This will be fine.
    public int RowCount { get; set; }

    // This will cause problems
    public CustomerEntity DisplaySubject { get; set; }
}

What seems to happen is that the designer is trying to deserialise the from from the designer "code" (in the separate file) and gets all confuzzled over the unexpected type.

One way to fix things is to not expose properties using custom types, but this is a pain in the (ahem) chair interface.

Another way is to tag the properties with the DesignerSerializationVisibility attribute, specifying Hidden (do not persist in initialization code).

If you're brave, you could look at using the DesignerSerialization attribute to control serialization yourself, but you're not likely to need that.

Bevan
That's certainly a similar scenario to what I've got (to reuse your example, this would be a validating customer control to be used in many different places throughout our application) -- Even with DesignerSerializationVisibility.Hidden, it's still crashing on load of the solution, if a dialog with one of our controls on it was open when the solution was saved.
Rowland Shaw