Some people were curious what I was getting at with my quick question yesterday, so now that I’ve got a little more time to explain, let me…

The problem that we’re looking at right now has to do with some subtle interactions between several new debugging features in VB 2005. One of the features is what we call Design Time Expression Evalutation (abbreviated to “DTEE”), which is just a fancy way of saying “you can evaluate expressions and call functions from the Immediate window even when your application isn’t running.” This was a nice feature from past versions of VB that we lost in VB 2002 and we’re happy to bring back in VB 2005.

The way DTEE works is that it actually starts up a copy of your application in the background when you try to evaluate something at design time. This background copy of your application is called the vshost process, and what the debugger does is set a breakpoint at the very beginning of the program to prevent the vshost application from actually running and doing things like putting up UI, etc. The vshost process then sits there in a debug break state, waiting for the user to ask to debug the application or do DTEE.

Another feature that I think we introduced in VB 2003 but are extending in VB 2005 is something called “Just My Code.” This is a debugger feature that filters out all the non-user code from places like the callstack window and prevents the application from breaking in non-user code. This means that if you call a .NET Framework API that throws an exception, you’re going to break in your code that called the API rather than way down in the Framework (since you likely don’t have any source code for the Framework). You can always turn off JMC in the options dialog if you want to see non-user code, BTW.

Now, let’s think about a new WinForms project for a moment. A new WinForms project contains no actual user code, because all the code in the hidden partial form class is marked as non-user code. So… can you see the problem? Right. You can’t do DTEE on a new WinForms project because the vshost process tries to put the breakpoint at the beginning of the program, but since the beginning of the program is not user code, JMC prevents the breakpoint from getting hit.

This isn’t a huge, huge deal – there are a couple of ways we can attack this problem. One proposed way would be to make changes to the debugger to recognize this kind of situation and handle it in a different way. Another proposed way was to change the way that we handle Sub New in the hidden partial class, perhaps making it compiler generated (and thus allowing us to fiddle with the way the debugger sees it). This would mean automatically generating the call to InitializeComponent as well, but what happens if the user specifies their own Sub New? Should we still automatically generate the call to InitializeComponent? If so, should it be before or after the user code in Sub New?

So the purpose of my request for feedback was to get a general feel for how we might have to proceed if we went down that path. The most important thing, of course, is to First, do no harm (to mis-quote the Hippocratic Oath). In solving one problem, we don’t want to create more problems for people.

I’ll let you know what we end up doing in the comments here… Thanks for all the quick feedback!