Why I prefer debugging in a terminal server session

In my previous post concerning my copious amounts of applications that I normally have running I offhand mentioned “There are actually other reasons I TS into the same machine. Specifically, it makes debugging some things _much_ easier. I can go into more details if you' like” to which i got a few responses back that people were actually interested in hearing about.  I'm sorry to say that it's nothing too incredible or life shattering.  You won't find debugging to be totally revolutionized, however, you might find it easier in a specific case.

In particular I'm referring to debugging events that happen based on UI interactions.  I'll start with a small (contrived) example.  Sy I'm trying to debug the generate method stub function feature that we added for whidbey:

It starts by showing you a tickler:

and then when you invoke the tickler (mouse or keyboard) you get:

Now, say I'm trying to debug what's going to happen when I click on that option.  I've got a few breakpoints set and I hover over the tickler.  The act of doing that causes one of the break points to get hit.  Ugh.  So I continue, but now the pop up never appeared.  This is because focus left the application and went to the debugger.  This is an example of a problem that you can have while debugging things that are related to application focus.  Say your application loses focus it commits or validates something (i.e. the item you just typed into a text box), but you don't want that to happen because you're debugging something else, then this can be incredibly useful.  In a TS session you can have an appliation have focus and changing focus in the main session won't affect the focus in the TS session.

The second thing that's helped out by having it be in a TS session is when you're debugging and you don't want paint calls to affect the debugging state.  If you have only one screen (Scary I know!) and your debugger overlaps the thing you're debugging, then when you hit a breakpoint the debugger will pop up hiding some of the program.  When you switch back, those regions will have been invalidated and will be forced to redraw.  If those redraw commands cause state to change or code to execute, then you could hit anothe breakpoint and all in all the debugging experience sucks.  For example, in the C# editor redrawinf lines will call into our code colorizer, which will cause semantic analysis to occur, which can end up hitting a whole lot of code.  In a TS session windows from the main screen don't invalidate windows in the session, so you won't run into these problems.

So, if you've ever run into these issues and have been highly frustrated by them, I recommend switching to a TS based approach.  I use it for 100% of the debugging I do because it has these advantages with no drawbacks that I've ever seen.

Edit: YMMV.  It's ideal for me, but may not be suitable for all debugging tasks.