Snubbed Again! No Edit-and-Continue for ASP.NET

Back Draft


Snubbed Again! No Edit-and-Continue for ASP.NET


By Jonathan Goodyear


Change is good - when progress is made. Most of us felt the burn of upgrading from COM-style thinking to the managed code way of life, but we accepted it as necessary to take advantage of all that .NET has to offer. With little question, however, the biggest controversy about .NET development was the conspicuous absence of the Edit-and-Continue feature. There was an outcry from VB developers struggling to justify making the switch to VB.NET.


Lack of Edit-and-Continue is nothing new to Classic ASP developers, but we did have it when we built VB COM components. In .NET, however, we were denied this most valuable debugging tool completely. In that respect, we weren't making progress; we were, in fact, losing ground. Based on the fallout of this omission in Visual Studio.NET 2002 and 2003, Microsoft assured us that Edit-and-Continue would be back in Visual Studio 2005 (previously code-named Whidbey).


What they didn't tell us is that the feature will only work in Windows Forms Smart Client applications (and other non-Web application types). ASP.NET applications are not scheduled to support Edit-and-Continue.


How can that possibly be? What the heck is going on? I posed these questions to several people at Microsoft while at the Global MVP Summit in Redmond in early April, including Brian Goldfarb, Product Manager for Web Development Tools. Brian's response was that they didn't feel that Edit-and-Continue was a necessary feature for debugging ASP.NET applications.


To understand his answer, you must understand a key difference in the way ASP.NET applications are deployed and executed in VS 2005. In VS 2003, all code-behind code is compiled into a single assembly that is placed into the /bin folder of your Web application. To make a change to your code, you must stop the debugging session, make the change, then re-build the project. In VS 2005, each page is compiled separately, enabling you to make a change to the ASPX page or code-behind class, save it, and refresh your browser window. You could get this same effect in VS 2003 by detaching and re-attaching from the ASP.NET worker process, but it wasn't as streamlined and simple.


The removal of the uber-assembly in favor of a run-time compilation model in VS 2005 helps, but it doesn't solve the Just-in-Time debugging problem as well as Edit-and-Continue does. First, it doesn't allow for the convenience of making a code change while in the thick of a complex process. It stinks to have to run the page over and over again after you make each code change. This is especially true if running the page requires any sort of scenario setup. Second, without Edit-and-Continue, you won't be able to make changes to code in component libraries in your solution into which your ASP.NET application makes calls.


To be fair, I will say that Microsoft isn't snubbing us arbitrarily. The way that the debugging process works in ASP.NET is vastly different than the way it works in non-Web application types. There are major technical hurdles that would need to be surmounted to make the Edit-and-Continue feature a reality in ASP.NET. Microsoft doesn't think that the demand is great enough to justify the effort.


The question really becomes, "What do you think?" ASP.NET developers represent an enormous percentage of the total .NET developer base. Your opinion counts. The folks at Microsoft aren't hearing any complaints right now, because surprisingly few developers are aware that Edit-and-Continue will not be present in ASP.NET in VS 2005; I certainly wasn't.


I think that omitting Edit-and-Continue from VS 2005 would be a colossal miscalculation that Microsoft will regret. The future will validate this obvious prediction. Edit-and-Continue is so important to me, that I plan to make VB.NET my preferred development language if C# does not support it (the future of that is hopeful, but still unknown). Those who are familiar with my history of commentary regarding C# vs. VB.NET can appreciate just how big a move that would be for me. If ASP.NET doesn't support Edit-and-Continue, we're back at square one.


Hey Microsoft! Don't make us wait for Longhorn. Give ASP.NET developers Edit-and-Continue with VS 2005.


Jonathan Goodyear is president of ASPSoft (, an Internet consulting firm based in Orlando, FL. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at




Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.