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
- Anonymous
February 03, 2004
Good to know it wasn't forgotten. - Anonymous
February 03, 2004
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#. - Anonymous
February 03, 2004
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? - Anonymous
February 03, 2004
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!). - Anonymous
February 04, 2004
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. - Anonymous
February 04, 2004
The comment has been removed - Anonymous
February 04, 2004
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. - Anonymous
February 04, 2004
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). - Anonymous
February 05, 2004
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.
- Anonymous
February 16, 2004
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. - Anonymous
February 17, 2004
The VS 2003 C# EE does not allow you to call methods on primitive types (eg string). We fixed it in VS "Whidbey". - Anonymous
March 05, 2004
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... - Anonymous
March 10, 2004
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? - Anonymous
March 11, 2004
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. - Anonymous
March 12, 2004
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 ;-) - Anonymous
April 22, 2004
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... - Anonymous
April 23, 2004
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. - Anonymous
April 23, 2004
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 - Anonymous
April 26, 2004
Trying again with the E&C link: http://blogs.msdn.com/jaybaz_ms/category/4881.aspx - Anonymous
July 16, 2004
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... - Anonymous
December 29, 2006
This post for some reason is very attractive to spammers, so I am closing it to new comments.