We got really interested in debugging workflows during our last batch of user research. One of the things we noticed was that even with Reflector installed in Visual Studio, the debugging trail can easily go cold when you hit third party code.
If you’re attached to a process in a debugging session and you break or hit an exception, the typical experience is either a rather useless greyed-out call stack, and the disassembly metadata view, or worse, if you’ve got “Enable just my code” switched on, an empty call stack and the faintly sad message “No disassembly available”. Neither is particularly helpful.
What we’d like to do is just light up the call stack, and stop this ever being a problem. In theory, Reflector can decompile and generate PDBs while debugging is happening, so that source code would always be there when you break, and all stack frames are always clickable.
If you saw Nick’s video, you’ll know that we’re getting there, but we’ve not quite nailed it. Technical investigation is on-going, but the main snag is getting the information we need out of Visual Studio. We can intercept a click on the stack frames, but we can’t quite enable everything or make the experience seamless.
To do this, we’ve had to switch off “Enable just my code” in the background. Is that a problem for most people? We think probably not, but by all means tell us about it in the comments – we’ve no interest in building something that’s just going to annoy people.
So the current state of play is that you can debug an executable without source, see source when you break, and click on greyed-out frames in the call stack. It’s not a perfect experience, but we hope it’ll help, and we’re working on making it a bit better.
Nick is currently trying to get it all working with debugging under IIS, too. We’ll let you know how that goes.