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:

https://sqljunkies.com/WebLog/donkiely/archive/2004/04/09/1991.aspx

https://jemos.com/blog/archive/2004/04/09/173.aspx

 

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

Comments

• Anonymous
  April 19, 2004
  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....
• Anonymous
  April 19, 2004
  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,
  
  Scott
• Anonymous
  April 19, 2004
  Better than nothing. :)
• Anonymous
  April 21, 2004
  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.
• Anonymous
  April 21, 2004
  The comment has been removed
• Anonymous
  May 04, 2004
  jhjkhjhjhjkhjkl
• Anonymous
  May 10, 2004
  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...
• Anonymous
  September 14, 2005
  The comment has been removed
• Anonymous
  July 22, 2006
  My start with VS 2005 has rather been a bit sluggish. I didn’t really work much with the Community...