Why no C# Edit and Continue?


I received an email from Bill T. who was asking why C# wont be doing Edit & Continue (EnC as we refer to it) in VS “Whidbey”. He asked “I’ve always wondered WHY that’s so much more difficult in C#.  Perhaps you could write something in your blog describing the technical issues that make it difficult.  I’d love to know some of the rationale behind it“. Here goes:

We on the debugger team obviously contributed a bunch of work for VB EnC to work in “Whidbey“ along with the VB compiler and CLR teams. For the debugger, the additional work to support additional languages is close to zero. For C# EnC the work would require substantial resources on the C# compiler and C# IDE teams. For “Whidbey“ we asked customers and prioritized Generics and Refactoring as more important than EnC for C#. It is not that the C# team has anything against EnC, it was just a resource issue. It is highly likely it will show up in a future version of VS.

Hope that helps Bill, and thanks for the question.

MSFT disclaimer: This posting is provided “AS IS” with no warranties, and confers no rights.

Comments (35)

  1. Louis Parks says:

    Good to know it wasn’t forgotten.

  2. moo says:

    I get asked this alot from old VB6 developers who are new to C#.

    As for refactoring, its good to have those tools but I always had problems refactoring (its near impossible) winforms with .resx files. Once you have an embedded resource its pretty much frozen in that structure and the only easy way to refactor the winforms is to redo them from zippo. It is this reason that I dont use the designer and do not support .resx files on C#.

  3. Philip Rieck says:

    Thanks for the responses..

    I’m curious though — why is it that VB.NET gets all three of the above (Generics, Refactoring, EnC), and c# has just the first two? Is there something cool for c# that took the extra resources that VB.NET isn’t going to have, or was it just that c# has less resources (or the additions to c# took more work than the additions to VB.NET).

    I’m hoping it’s the first choice, and that we’ll see something neat. I’ve looked a bit at the PDC bits, and it seems that refactoring support in c# is enhanced from vb.net. Can you say if this will be the case with the release of Whidbey?

  4. Dmitriy Zaslavskiy says:

    Andy, once we are on the subject for debugger improvements, where should we send our wish list/comments.

    For example I would like to see in VS Debugger ability to select which members to see in property views (Like HEX switch). For example private on/off, internal on/off, properties on/off (very important!).

  5. moo says:

    I want to have intellisense on the watch window so i can enter this. and it pops up the members I can select to watch.

  6. Wallym says:

    Thanks for the info. Edit-n-Continue is an important feature to me. The projects that I work on are typically fairly complicated, so the ability to make a chance without having to go through a 2 to 3 minute process of stopping the debugger, making the change, restarting the debugger, and then navigating to the point within the application that I was at. I prefer the c# language and I felt a little left out when I saw that vb.net would get Edit-n-Continue and c# would not in whidbey. I know that there are a lot of purists that think that having EnC is somehow bad and evil and makes programmers lazy, but EnC is a good thing in my book. Thanks again for the explanation. Please get EnC into the next version after Whidbey…….please, please, please. :-)

    Wally

  7. Andy Pennell says:

    To Dmitry and moo, I hear you and I understand. Please be a little more patient. I can’t tell you what is in post-PDC "Whidbey" builds, but it should make you happier.

  8. Andy Pennell says:

    To Philip, sorry but I can’t compare refectoring in C# to VB in a definitive way, but I think the C# one will be better (of course I would say that wouldn’t I).

  9. Jonathan says:

    C# will definitely be the better one ;)

    EnC? I enjoy being able to modify code, whilst debugging, but it does not mean, that the environment has to then ‘continue’. C# is fine the way it is in my book.

    Coding in both C# and VB.NET (depending on client requirements) my hope is that VS.NET does not separate the way it handles the two languages too much, as it can be a pain, when switching back and forth.

  10. John Hamm says:

    I’d just like to be able to debug the following code in C#:

    string s = "It’s a mystery."

    string s2 = s.Substring(9,7);

    Console.Writeline("The debugger doesn’t know that the value of s2 is " + s2);

    Apparently, C# cannot evaluate s.Substring in the Watch window.

  11. Andy Pennell says:

    The VS 2003 C# EE does not allow you to call methods on primitive types (eg string). We fixed it in VS "Whidbey".

  12. devscrapbook says:

    From a Microsoft’s employee reply to my question in a newsgroup: "If you did mean "Edit & Continue" for C#, as far as I know we are not planning support for it in Whidbey. Here is a link to Andy…

  13. Gary Hoffer says:

    EnC is not just a nice to have feature…As I found doing C++ windows programming if you could make a quick change and stay in the same context, re-executing the code "in-place" you could save hours trying to reproduce a problem. I really don’t understand if all .net languages are based on the same underlying MSIL why VB debugging is "easier" to implement EnC than C# or J#, or COBOL for that matter.

    I feel the same about this as some VB programmers must have felt about /// commenting in C#. Why not?

  14. VBandi says:

    Well, I remember first meeting E&C in Java like… 5 or 6 years ago? It was in Symantec’s Visual Cafe, a Java editor long suprassed by others. I just loved it, even tough I did not know what refactoring was about at the time. OK, so I’ve learned a lot since, and I WANT both (phew, am I arrogant…)

    But, dear Microsoft, have you considered this: How easy it is for a third party to add a refactory plugin to VS? Yes, it’s doable, there are already a few cool products out there in this area. And how easy it is for a third party to enhance the CLR and/or the debugger to be able to have E&C for C#? I doubt, that any ISV will have the knowledge and influence to the .net Framework itself to pull a C# E&C out of the hat. You said that it would "require substantial resources on the C# compiler and C# IDE teams". I can see that the IDE is pretty extensible with VSIP, but how could an ISV extend the compiler?

    The .net developing experience (which I love by the way) is not only determined by MS tools – it is also determined by the community – ISVs who provide additional tools. I think MS made the wrong decision. If it had opted for E&C, we could still get refactoring from third party companies. Now VS will have refactoring in 2005 (if no further slips occur), which will probably be decent, but not great. And MS refactoring won’t receive further functionality for years, while an ISV’s refactory tool can easily add a new refactoring every month. So, some will still buy external tools to get better refactoring.

    And that means, that we won’t see C# E&C for another 4-5 years, which will put C# 10 IT years (that’s 100 normal years) behind Java in this respect. That’s the lifetime of two software generations.

  15. RichB says:

    But VB.Net v2 has Generics and Refactoring and E&C

    How could the VB team manage it but the C# team couldn’t? Do they have better developers than the C# team ;-)

  16. Eric Newton says:

    EnC lost out over Refactoring??? UG guys! Come on!

    I can refactor manually just fine. I cannot EnC without restarting the entire app. Is there a plan to refactor and EnC in the future? J/K!

    Its absurd that refactoring won out over EnC. Wait… what did refactoring have to do with the C# compiler guys? Wasnt that all in the VS project? I’M confused now. Maybe i’m not understanding what refactoring exactly is…

  17. Andy Pennell says:

    Yes, there is a plan to EnC in the future.

    The C# compiler generates the parse/bind trees that the C# IDE refactoring code needs to accurately refactor your code. Refactoring is a lot more complicated than you seem to think. Check out the Whidibey Community Drop released recently for some of the amazing C# refactoring you can do now.

  18. jaybaz_MS says:

    Eric: For some more thoughts on C# Edit and Continue, see my blog, especially my E&C posts:

    http://blogs.msdn.com/andypennell/archive/2004/02/03/66949.aspx#118684

  19. Andy Pennell says:

    AC/DC: Do you mean remote debugging? No, that’s not going away. Ever. Things might change (transports, security etc) but I can’t forsee a time when remote debugging can go away. If you are talking about .NET Remoting then I have no idea, that’s not my area of expertise.

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

  21. andypennell says:

    This post for some reason is very attractive to spammers, so I am closing it to new comments.