Edit and Continue

I'm wondering if anyone has ever used this amazingly powerful feature that was (if I remember correctly) first introduced to the .NET world in Visual Studio 2005?

The reason I ask is that it has the caveat that it is disabled when the debugger is attached to existing process. Which means it doesn't work with website code, webservice code, Silverlight code, SQL Server CLR types, basically everything except desktop apps. And who is writing desktop apps these days?

Is there any chance of this being fixed somehow in future versions of .NET? Being able to change code while stopped in the debugger was such a great productiviry boost in classic VB, it's the one thing I really miss since .NET came along.

Doesn't work with any x64 code either.

I kind of feel that the need for edit and continue drops if you're doing TDD.  The benefit of Edit and continue for me was always for the problems that required a lot of steps to get you to the problem code, and since adopting TDD I don't seem to feel the need for it anymore.

I used to use it quite a lot in ... Quick BASIC
And....actually I am writing desktop apps now (WPF/C#/C++CLI)

@rhm:Sure you can use E&C in web applications. Just make sure you check the"Enable Edit and Continue"  checkbox in the web tab in project options.

@lucianoc:Only works with Cassini   I'm using IIS. I wonder if it'll work with IIS Express when support for that comes in VS2010 SP1? Won't help me at work anyway as the most modern thing I get to use here is 2008.

It works in VS2010 SP1 Beta with IIS Express!!!

I use this all the time. You get an exception during runtime, see where the problem is, and fix it, all without needing to restart the debugger. There are some things you just can't unit test efficiently.

This feature has been available for quite some time over on the VB side (since at least version 6 and probably earlier).

I also use this; but not as much as a colleague of mine who seems to do most of his development while running the code!

Very useful when you're deep in the stack and see an obvious bug so you can fix it without the rigmarole of stopping and getting the system back to that point.  Real time-saver.

EDIT : Also very handy being able to drag the stack pointer to a previous point and re-run the code after the fix.

Herbie

Yes I also use this all the time. The other day a coworker showed me how to use one of the controls that he implemented, and without thinking too much of it, I simply changed my code in place while the debugger was running, pressed F5 and the control instantly started working correctly (it takes quite a while to start up the application and navigate to the view that contains this control). He was so surprised to see this work that at first he wanted me to do it again to prove that I didn't "cheat" somehow. The look on his face was priceless.

Anyway, to the OP's comment about desktop apps becoming less relevant... Has there really been such a big shift that one can actually see this in job posting requirements etc? Personally I don't like any type of web development - it just bores me to death. I love writing "native" .Net applications since my pet projects at home always involve either 3D games (XNA) or audio applications (yes, it is fun writing "realtime" applications in .Net).

I use it as much as Visual Studio allows me. With a lot of restrictions (32-bit only, can't edit anything with a lamda expression, XAML) it's very hit & miss on when you can use it without rebuilding & restarting the app. This is especially painful on DI driven apps where the modules aren't hard referenced and you're forced to do a rebuild. Builds on any sizable app are really expensive so I hope Microsoft continues to support and improve this feature. TDD is great and all but it falls apart when your working on an ever changing GUI. I know, I know, things should be designed & spec'ed 100% before writing a line of code but in reality the acidemics loose this extremely inflexible argument because the customer is always right and demands an agile development response to their needs and wants.