I'm looking forward to VS.NET 2005 like everyone else, but the one killer feature that will absolutely compel me to upgrade on day of release is Edit and Continue. I had no idea exactly how much time I spent editing live code in VB6's debugger until I lost this capability in VS.NET. It is my one serious regret about .NET-- which in every other respect is a massive improvement over VB6. I am sympathetic to the timeline crunch that forced Microsoft to drop the feature, however:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/06/edit-and-continue.html
I’m surprised this never got a comment.
Edit and Continue is great for VB and for quick fixes in other languages too… personally though I never use it, not out of dislike, but just out of practicality. Typically my code breaks somewhere after whatever needs to be fixed was executed, which completely nullifies the value of Edit and Continue. The classic example (and one of the most common problems afaik) is allocating memory, you allocate /then/ check if the allocation was successful… so Edit and Continue can not help to fix these ones…
Maybe its because of my silly C++ code style… I can remember using it loads in my VB6 days.
I may be missing something, but this is something that Those with a Lisp ™ have had for decades, with the REPL (Read-Eval-Print loop). Type in a hunk of code, hit enter, and see if it does what you want.
This is actually really awesome when doing websites, especially with a threaded Lisp. After trying it on a simple app, and fixing a bug on the server without killing any connections, I’ve been hooked.
Edit&Continue in C++ at least is a horror - not because of its own merits, but because you can’t practically use it and because Microsoft broke the C++ standard in implementing it. Not breaking it in an academic “it’s not 100% conforming” way, breaking it in a “I’ve run into the problem and can’t fix it - and god knows what else” kind of way.
C++ tends to be directly related to the assembly output that it creates, as well as having a direct mapping on the stack. All of these are known and good - but don’t cooperate nicely with edit&continue. Stack-based objects, re-running the same calculations multiple times, all of these are problems that you introduce with edit&continue.
What about just not debugging?
You might be interested in this suggestion on the newish VS uservoice forum: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2035769-make-edit-and-continue-work-more-globally
It basically says “let us use Edit and Continue even though we’re using features that were introduced after Visual Studio 2005”…