This only really works well for jumping around within a single function, but it can be useful for "trying again" with a different value - you break after a loop, use the debugger to change the variable values, and then jump back to the top of the loop. You can use the "move execution point to here" feature (actual name will depend on your debugger, of course) to set the line being executed. While current debuggers don't save the state, they do let you go back, to some degree. At any time during debugging, you can go backward and forward in time to determine where an error occurred."Įdit: I starting evaluating the most (1) recent CTP drop (31/10 - October 08) of Visual Studio 2010 and they seem to have an early version of the historical debugger implemented. When an error occurs, you can quickly find the root cause by investigating the information that was recorded by the Historical Debugger. "Visual Studio Historical Debugger captures and records what the application does while it is running. I've found this definition of the new Historical Debugger from a blog entry by Maor David ( here): There's a bit more about it in this entry located here (this one is for the April 2008 CTP of codename 'Rosario')
They are implementing almost exactly what you're describing in #1 - there is a screencast about the new "The Historical Debugger" in Visual Studio Team System 2010 on Channel 9. It sounds an awful lot like you will want to grab a copy of Visual Studio 2010.
0 kommentar(er)
