Remarks: Edit and Continue in ASP.NET

Jonathan Goodyear writes a fairly balanced and technically accurate overview of the Edit and Continue story in ASP.NET, even if the title is somewhat negative J.  Since I was quoted, I wanted to make sure to paint the entire picture, without word limit constraints…


A few technical clarifications – first Edit and Continue *is* back for VB.  Not only is it back, but now it includes numerous improvements including improved support for working with run-time exceptions that occur while debugging and visual indication of edits that cannot be applied while under the debugger.  In the VB 6 and classic ASP days, there was Edit and Continue for client apps, but there was no Edit and Continue for the Web.  The uproar in Visual Studio .NET 2002?  The feature went away for client applications.  In Visual Studio 2005 for VB it comes back in a big, much improved way for client applications.  The Web – we retain the status quo.


Now – making that decision was not easy.  We thoroughly investigated the technical challenges that would need to be overcome in order to enable this on the ASP.NET side.  While these challenges were achievable, the feature tradeoffs that we would need to make were high.  The next step was to conduct research – we held focus groups and did studies to determine what the most important features were to our customers.  We had a trade off to make. 


E&C for ASP.NET was certainly a requested feature, but in order to implement it would have meant not implementing many other features that fell above it in the list.  We looked at the alternative that Jonathan describes as well, with the save/refresh style debugging (where you don’t have to stop the debug session).  While it is not E&C, in many scenarios it is extremely useful.  Now don’t get me wrong, there are certainly scenarios as Jonathan describes where this method breaks down, but it all comes back to tradeoffs and they are never easy.  This is one that we made.


You are already talking – check out these comments:


But what about you?  What is your take?  Maybe there is some selection bias here, but be honest, let me know your thoughts.


Comments (12)

  1. This is the first I’m hearing of this…I was under the impression that if you’re using VB in Whidbey, you’ll have E and C…even in ASP.NET. Not having E and C is a huge,huge pain….

  2. scottgu says:

    Actually, support for editing ASP.NET applications while in debug mode is supported in Whidbey with Visual Studio.

    Specifically, you can F5 to run with the debugger, run a page, step through in the debugger, and then see the output. You can then make a change to code, hit save, then run the page again and step through the debugger with the new source and see the new output.

    This wasn’t supported in VS 2002 or 2003 — but is supported in Whidbey for both VB and C#.

    What isn’t supported is edit and continue support where you can edit code while the debugger is stopped on a callstack. Instead, you need to wait until the request is done, then make the code change, then request the page again (for example: push a button a second time).

    We think this gives you about 90% of the experience of full Edit and Continue for web applications. The nice thing is that it also works for all languages.

    Hope this helps,


  3. Sean Chase says:

    Better than nothing. 🙂

  4. Jeff Kirwan says:

    Personally, I don’t miss E&C. Never really used it, don’t intend to start. It’s really a philosophical decision more than anything. Debugging should be a process, not a "quick fix". By using E&C, you are vulnerable to making snap decisions which could affect the rest of your application in ways you did not take the time to consider. In my mind, it’s much better to take a step back, analyze the source of the error, and implement a fix after considering all of the consequences.

  5. chris willis says:

    I have been impatiently counting the days until my beloved E&C (with VS2005) would return my debugging productivity back to me. Not supported in ASP.NET?!? ASP.NET is where you need it the most — we don’t do win forms anymore! I now have to wait at least 60 seconds for ANY little change in code to recompile and get back to where I was, and this is a major annoyance and productivity killer. With VB6 COM objects behind ASP I had to wait ZERO seconds to fix something and move along. Now my days are filled with watching the output window while VS2003 does all that stuff it does just to fix one frikkin line of code. I thought the problem would finally be solved, BUT NOT FOR ASP.NET?!? E&C is what made classic VB so great. Please, please, please Microsoft, put E&C in ASP.NET!

  6. ghjghghghjg says:


  7. dan owens says:

    wow – I totally agree with chris willis above – E&C is by far #1 on my list – even moreso that getting remote debugging to work. The problem is magnified with the time it takes .net to stop and restart then renavigate back to the code.

    On the otherhand, I do have more time to get thru my email while waiting for my app to recycle…

  8. Tim Bushell says:

    Astounding. What an appalling decision, Microsoft. Do you have any idea how much time and productivity is lost by trying to debug web applications without e&c???? I estimate at least 40% slower without it.

    I have been absolutely hanging out for this, and to hear that everyone bar us ‘plebs’ in development will get it is devastating.

  9. My start with VS 2005 has rather been a bit sluggish. I didn’t really work much with the Community…