Tim Anderson's ITWriting

June 15, 2006

Debugging Visual Studio design mode

Visual Studio 2005 and .NET make it easy to create custom components, but design mode issues can be troublesome. This is when you are working with your control in the Windows Forms designer, changing its size and position and setting its properties. By default, most of the code in your control runs at design time as well as at runtime, but design-time failures are harder to debug and can have drastic consequences.

Here's a case in point. From time to time I work on the HtmlEditor, a wrapper for MSHTML, the rendering and editing component in Internet Explorer. I had a bug in my code which caused Visual Studio to crash completely every time I deleted the control from a form, or closed a form in the designer. I puzzled over this for some time. If I commented out the Dispose method, the bug didn't occur, so it appeared something was wrong there. However, the Dispose method looked fine to me, and even if I modified it to do nothing, the crash still occurred. It was no use setting breakpoints in my code, since you can't debug at design-time. The only clue I had was that Visual Studio was reporting an unhandled System.ObjectDisposedException.

Or maybe you can debug at design-time. Here's what you do. Open up two instances of Visual Studio. In the first instance, get ready to repeat the design-time steps that trigger the bug. In the second instance, open the Attach to Process dialog (Ctrl - Alt - P) and select the first instance of DevEnv.exe. Then open the Exceptions dialog (Ctrl - Alt - E) and check Thrown for the exception(s) you want to troubleshoot. If you've done this right, the second instance of Visual Studio reports "running" in the title bar, even though no project is open.

Now trigger the bug. At this point, the debugger in the second instance of Visual Studio springs into life, breaking into the code at the line that has thrown the exception. You get the call stack, variable inspection, disassembly, everything you need to find the problem.

In my case, I discovered an obvious bug that was nothing do to with the Dispose method. Easy to fix and all was well.

To be honest, I reckon Visual Studio was partly to blame. A bug in a custom control shouldn't make the whole IDE crash. Furthermore, part of the problem in my case was that the control's DesignMode property, which is meant to tell you whether it is designtime or runtime, was reporting False when I would have expected it to be True. DesignMode inspects whether the control is sited on a design-time form. My code was running in the moment after the control had been removed from the form, but before it was fully destroyed; therefore DesignMode said False and code that should never run in the designer was trying to execute.

In addition, Visual Studio's form designer is not particularly reliable. I've seen issues like forms shrinking themselves, form designer white-out, and the mysterious "Unable to load one or more of the requested types" stack trace which gets displayed instead of your beautiful design, partially addressed by this fix.

It all increases my appreciation of Borland's Delphi, which had reliable two-way code and visual design working ten years ago. Still, there's always the next service pack to look forward to.

Tags: visualstudio .NET microsoft