views:

123

answers:

2

C#, VS2010, WinForm application:

Sometimes I do have the problem that I get an error message when opening some of my controls / forms. All code compiles and the application runs properly. Opening the control in the designer gives me:

The designer loader did not provide a root component but has not indicated why.

From my experience I can tell, it is usually something in my code which does not get properly initialized, e.g. a property is not set which is somehow available at runtime, but not when opened with the designer. The only issue is, that the root cause is hard to find.

Q: Is there a chance to somehow use the debugger when the designer opens my component in Visual Studio 2010? That would help a lot and the problem tackling is most likely a matter of minutes then.

Remark: Just to make this clear, I know how to use the debugger ;-), I only have no idea how I could tell VS2010's designer to open my control in Debug mode.

As of 2nd SEP 2010 added:

Thanks for your help. Basically it is the MSDN Library article describing how to do it.

  • I have managed to set it up and run the second instance (there was not much to understand how to do it).
  • It only fails in my case, because the 2nd VS2010 instance (debugging Design Time) fails to find the symbols for my custom control. I have added the symbols manually under Debugging / symbols. No result, still "Breakpoint won't be hit because of missing symbols"

BTW, using this approach it is helpful to exclude some stuff from the symbol loading (via modules window), because this will safe a lot of time.

Now if have to figure out how to get the symbols resolved and then I can tackle the issue.....

A: 

To debug your control in design mode, you need two instances of Visual Studio. In the first instance, open the project which contains this control source code. In the Project Properties, Debugger, set command line which calls another Visual Studio instance (msdev? don't know exactly for VS2010 - take it from the shortcut), Then execute "Start Debugging" command. Another Visual Studio instance starts. In this instance open client project which uses your control on the form.

Alex Farber
Thanks Alex, this is the right approach. The MSDN article at Hans' answer describes how exactly to do it. But your answer is also correct.Remark: My reputation here is not yet high enough to vote for your answer.
Horst Walter
+1  A: 

The vast majority of design time problems with custom controls are caused by code in the event handlers or method overrides in your control running at design time as well as run time. That's normally desirable, you get instant feedback when you change a property in the Properties window for example.

But not desirable when the code depends on something that's available at runtime but not design time. Like a dbase connection or a file that's stored in the build folder. That can generate exceptions and Visual Studio isn't very robust against handling exceptions at design time. Worst case, you can crash VS to the desktop without any diagnostic. But anything is possible.

Review the code in your control and make sure that the bits of code that should only run at runtime are wrapped like this:

if (!DesignMode) {
    // etc..
}

Hard cases can be diagnosed with the debugging tips in this MSDN Library article.

Hans Passant
Thanks for the feedback Hans. First I have to find the root cause before I can leverage the "DesignMode" condition.However, the MSDN article describes how to do it, only have to figure out the symbol issue (as described in the original posting)
Horst Walter
I would *definitely* do this the other way around.
Hans Passant