An update on C# Edit and Continue

There has been a lot of discussion, both here and on Andy's blog about C# E&C.  Some folks really want it badly.  So, I figure you deserve an update on its status.

At the last PDC, we got a lot of strong feedback along the lines of “We understand why you selected Refactoring over E&C, and we think you made the right choice, but we really want E&C anyway.”

Here's the strongest statement I can make: We're committed to getting C# Edit and Continue into the hands of our users as soon as we can, without compromising all the other commitments we've made.

For example, the development and release of Longhorn and Yukon are both tied to the progress of VS Whidbey.  We don't want VS, LH, or SQL to slip, right? 

E&C has tight dependencies on the CLR team.  The CLR is such a critical component that we have to be very careful with what kinds of requests we make on them. 

E&C is a complex feature.  It will take a lot of dev work + testing, spanning several feature teams.  We'll have to carefully coordinate to make this happen.  The teams involved are going to have to make a very significant commitment of resources, from the best people. 

There is some attention on C# E&C at the highest levels - my boss's boss's boss's boss's boss is interested.  If he makes a decision about E&C, then we'll carry it out - whatever the timeline, scope, etc.

When customers ask for something so strongly, we'd be irresponsible not to respond.  We're taking your feedback very seriously, and doing deep analysis to decide on the best course of action.

So what does this mean?  Well, it's hard to say.  We're working on finishing up the first Beta of VS Whidbey, which certainly won't include C# E&C.  I hope it won't take any longer than the release after Whidbey, but that's possible, too. 

Anyway, we're definitely looking at this closely, and it definitely will happen some time. 

Comments (40)

  1. Joku says:

    Is E&C in scope such a feature that it would not be reasonable to upgrade it on the VS2005 on a service pack? Technically I find it hard to believe it would increase the service pack size much, but the marketing dep. may think such "big" feature would warrant a VS2006 for example ..

  2. jaybaz [MS] says:

    Traditionally Service Packs have been limited to just critical bug fixes including security issues.

    We want to make sure that every user will pick up every service pack, which means they need to be comfortable with the risks of picking it up. Suppose you’re an airline builder or NASA and we offer an SP of VS. Will you take it?

  3. Wallym says:

    While some biggots are not interested in E&C, some of us that work in the trenches are interested in E&C. I find it very frustrating that when I work on a project that takes me a minute or two to get the app/debugger into the right state only to find that I need to change some database call that I fat-fingered. The ability to use E&C in a C# winforms project would improve my productivity imensely.


  4. Corrado Cavalli says:

    This sound like a great productivity boost (and C# users will love it!)

  5. James Hancock says:

    Ditto! We’re talking 30 to 60 minutes a day per programmer on the large project that I’m working on.


    You want people to upgrade and pay money for Whidbey? This is the surest way I know how.

  6. Snorrk says:

    From what I understand VB.NET.2005 will have E&C? One would think that C# and VB.NET share a lot of architecture (with regards to the CLR f. ex.) and therefore it should be easier to add C&S to C# when VB.NET already has it?

    If we get E&C in C# I’ll clean my room every day and be in bed by 10 o’clock and only eat candy on Saturdays and be really nice to my little brother and always finish my dinner and…


  7. cwillis says:

    The ASP.NET team says E&C will NOT work under ASP.NET for ANY language for VS 2005!

    So for many (most?) developers, the whole E&C discussion is possibly pointless until they complete that task in ASP.NET 2.x or 3 or 4…

    I certainly wish it were otherwise – I can’t stand having to wait no less than 60 seconds to recyle everything to fix a single line of code. E&C was probably one of the best things about ‘classic’ VB, and I think all languages should get it ASAP.

  8. Jay, as sort of an "eat crow" on my part, refactoring is indeed very, very cool! 🙂

  9. VBandi says:

    I think that it was wrong to prefer refactoring over E&C. I agree that refactoring is often more useful, but the fact that there are at least 3 third-party refactoring products out there shows that it is possible to do outside of Microsoft. However, as your post indicates, E&C is not something that a third party could implement, since it requires tampering with CLR, etc… So, now we only get just one more refactoring tool (possibly not even the best one), and absolutely no way to get E&C for C# for 2-4 more years. And even the refactoring tool won’t be updated, won’t have new features added, so sooner or later I would switch to another tool that offers more refactorings.

    Somebody from Microsoft mentioned that one of the reasons they have choosen refactoring over E&C is that for Java IDEs, the built-in refactoring tools are very highly praised, while there is not much enthusiasm about E&C. Well, since Java had E&C since cca. 1997-1998, I can see how Java ppl got used to it… And we will be lucky if we get E&C for C# 10 years after Java has had it.

  10. cwillis says:

    Java has E&C? Is that true? Which environment? I’ve always used Microsoft tools, and never thought E&C was available anywhere else. I may give Java a serious look if E&C is available on that side of the fence. I got hooked on E&C in VB, and I can’t stand that its gone missing.

  11. E&C wouldn’t be nearly a problem if the VS debugger was faster at doing things. VS2003 starts up slow (and hangs a lot during startup for me), and takes a long time to be "ready" after an exception is thrown.

    On the plus side, VS2005 simply flies at this and it’s so fast I don’t notice any slowdowns at all when the debugger is started and an exception thrown.

  12. jaybaz [MS] says:

    VBandi: your point is definitely one we’ve considered, and one I should have mentioned in my post. We’re the only ones that can do C# E&C, but not the only ones that can do refactoring. That fact is motivation to build it.

  13. GnuVince says:


    Java has E&C? Is that true? Which environment? I’ve always used Microsoft tools, and never thought E&C was available anywhere else. I may give Java a serious look if E&C is available on that side of the fence. I got hooked on E&C in VB, and I can’t stand that its gone missing.


    E&C has been available in many, many languages outside the C family. I am a Smalltalker, and this is nothing new to us, every Smalltalk environment has had that for quite a while.

  14. Mike Woodhouse says:

    I suspect that the clamour for E&C in C# may have been a relatively recent phenomenon, more recent than the point at which the decision to focus on refactoring was taken.

    Why? AFAICT, a lot of VB developers are switching to C# and they’re used to E&C. As .Net gains market share, the number of voices is naturally increasing. In fact, one reason for switching may well have been the absence on E&C in VB.Net… Certainly that’s been a major factor in my own case.

  15. Could you explain why it’s so difficult to have edit & continue in C# if you have it in Vb.NET. What are the internal mechanics that make it different ?

  16. jaybaz [MS] says:

    The work in the CLR and Debugger applies to all E&C. The language-specific work is very significant though – the rules to understand what an edit in a given language means. Things like Anonymous Methods makes the C# E&C story a bit more complicated, too.

  17. BillT says:

    One of the things you asked for was features that have high utility, but low impact on the dev process (my paraphrase). I can imagine one thing that is a step toward edit-and-continue, without the huge impact. I call it "nonbreaking edit". Edit-and-continue implies integrating edits into the current running debug session, but this doesn’t go that far.

    Currently, in VS.NET (both VB.NET and C#), when the programmer edits a file ever-so-slightly, the current run is "broken". To continue running or stepping, the code must be recompiled. How about making it so that we can contimue running the current session without "breaking" it?

    This would let us make multiple changes that would be incorporated in the next compilation, but that do-not-affect-in-any-way the current exection environment.

    Often the edits I’d like to make are simply adding/changing a comment (esp. a TODO item), or reformatting something slightly. But I don’t want even massive edits to break the current debug session. I can easily live with the yellow "Next Statement" indicator not matching the line-of-code in the editor.

    My essential motivation is that I want to improve my code NOW, the instant I notice an improvement, without impacting the currently-executing debug environment.

    This isn’t an all-or-nothing feature. Any step in the right direction would help. Even partial implementation is useful. For example, "comment-only non-breaking edit" would be a great help.

  18. primeMover says:

    As Richard Grimes in his article available at

    points out, E&C is a feature that provokes quick fixes which has a serious impact on the quality of the code.

    Being a corporate developer in a company that faces the struggle to port a 600+ dsps project from vs 6 to vs 2003, I’d recommend MicroSoft should better have an eye on QUALITY.

    Just a thought: The cost of migrating our project from VS6 to VS 2003 is about the same as porting the whole system to Debian. MS did a great job in selling services.

    So now we’re burning hundreds of PSfD hours just for upgrading the development environment to VS 2003. And we’re not going to take that road again with VS 2005 just because someone at MicroSoft missed the point or the "community" wanted it that way.

    Seems like blogging established a democracy of the loudest in redmond.

  19. jaybaz [MS] says:

    Bill: can’t you edit your C# while you’re debugging? I thought I made this work when I was on the debugger team.

  20. jaybaz [MS] says:

    prime: That’s a very interesting point of view in Richard’s article. Thanks for posting it.

  21. Chad Myers says:

    I’m just confused about how this decision could’ve ever been made in the first place.

    Does the C# compiler team have anything to do with refactoring functionality in the IDE?

    Why is it so much harder in C#?

    Is MS making Visual Basic.NET a higher priority than C#? It seems so.

    It sucks that you have to defend it Jaybaz, but what I’m most pissed about is that someone thought that this was a good idea in the first place.

    At some point, some PM said "OK, VB gets Generics, Partial classes *AND* EnC, but C# only gets Generics and partial classes. OK, good idea!"

    Personally, I don’t care much for EnC or not, but I’m frustrated by the apparent lack of focus on C# and the prioritization of VB.NET over C#.

  22. Chad: An emphatic "Yes, the C# compiler is tightly bound to refactoring support". I can go more in depth in this. But that’s the basic answer.

    No one said it was "much harder" in C#. But that said, it isn’t a simple problem. It takes a lot of work to get something like E&C working for a language. You ask if MS is making a VB.Net a higher priority than C#. The answer is "no. however, VB is making E&C a higher priority than C# is. And, due to that, C# chose to persue other features in this product cycle".

    Note: when these decisions were made it was done with the following argument (ala fight club) "we have X amount of resources. Based on communication with our customers they want A and B. We only have time to do A given X". So yes, somebody made this decision but is was never based on "let’s screw over the developer" but rather "what would be the best for them given our constraints"

    You say you don’t care much for EnC. So i’m kind of surprised. Would you have rather us do EnC and then cut something you are interested in?

    It’s because of feedback like yours which caused to say "we think that refactoring will really be the thing that benefits our user" and so we invested heavily in that area.

  23. Edit: I didn’t mean for the last part of that to come off sounding like a threat. 🙂

    What I was trying to ask was:

    "Which would you prefer, maintaining parity with VB, or including the features you care about?" 🙂

  24. jaybaz [MS] says:

    Cyrus: Actually, we got really drunk and then had a meeting to figure out how best to screw over the developer.

    <evil grin>

  25. Eric Newton says:

    Well as much as I’d really like to see EnC as soon as possible, refactoring will be a benefit.

    And with EnC in the VB camp, at least you’ll be able to finally edit the files at runtime in VB projects too 😉

  26. Ray Burns says:

    It’s all about time:

    1. Three minutes are lost every time I have to make a code change and have to rebuild and restart.

    2. More minutes are lost when I get bored waiting for the restart and go off to do something else.

    E&C would save me 30 minutes or more every day. Refactoring might save me 30 minutes every month, if that. Besides I can use a third-party tool for refactoring.

  27. mahara says:

    I think, you (VC# team) must have worked hard to do refactoring; you must have spent a lot of "investment" in it. If you then change your mind to add E&C feature in Whidbey, just make sure you have done refactoring as best as possible or you may be trapped in situation where nothing best has been done in both area :). I believe that there is so much more to do, to improve the refactoring, to make it more than just like a third-party refactoring tool. I need it, the same way I need E&C as my second priority, for now at least.

    By the way, I completely don’t understand why the implementation of E&C should be done in CLR too. Is this by design (the architecture)? If it’s, then I don’t think it’s an inefficient one.

  28. mahara says:


    … If it’s, then I don’t think it’s an inefficient one.

    Should be:

    … If it’s, then I don’t think it’s an efficient one.

    Sorry …

  29. [href=// title="wangzhidaquang"]

    [href=// title="jingpingwangzhi"]

    [href=// title="mianfeidianying"]

    [href=// title="dianyingxiazai"]

    [href=// title="MP3 free download"]

    [href=// title="diannaoaihaozhe"]

    [href=// title="duangxingcaixingxiazha"]

    [href=// title="dianyingxiazai"]

    [href=// title="yinyuexiazai"]

  30. mr_bliss says:

    This whole topic completely caught me off guard. The first time I heard the VS team discussing features in Whidbey, I swear they said E&C would never make it to C#. Their point was it’s a VB mindset type tool and the large base of VB devs were demanding it; apparently less demands were made from the C# camp. Now public Microsoft comments make it sound like MS might implement this feature in C# sometime down the road. That’s great! I say everyone take this opportunity express their opinions on the issue and maybe we’ll see it in the next version. I issue a strong vote for E&C in C#

    Finally, it’s too bad more effort wasn’t put into the CLR design to accommodate this feature. It seems all the effort that went into making VB E&C work could have potentially been added as a core component of the CLR and hooked into by each language.

  31. My start with VS 2005 has rather been a bit sluggish. I didn&amp;#8217;t really work much with the Community…

Skip to main content