What’s coming up for C# beyond Whidbey?

Diego asks,

Now that C# 2.0 is almost here, I’d like to know about features that were left out from this release and planned for the future?

I can’t think of anything that I’d say was “left out“. There are a few things that we’ve been talking about

There are a few things that we’ve been talking about. Unfortunately, I don’t think I can talk about them now.

The basic problem is one of expectation. When we first start talking about something, we’re always in the exploratory phase. That’s a long way from the “already implemented“ phase when we usually start talking about features.

[Update: Marshall asks whether E&C was left out, or just postponed. Refactoring rated higher than E&C, but we do understand the utility that E&C brings, and we also have gotten a lot of customer feedback in that area. Oh, and to the best of my knowledge, the VB version of E&C does not support web apps. ]

[Update: Mike asks about delays in Whidbey. While I generally know when we have slipped our schedules, I don’t track when (or wheter) we’ve communicated those slips, so I’m going to avoid those sorts of topics. ]

Comments (13)

  1. Marshall Brooke says:

    Was Edit and Continue "Left Out", apparently in favour of Refactoring, or just postponed? This is my biggest gripe when debugging large ASP.NET apps when there are very simple code issues that could benefit from E&C.

  2. Mike Dimmick says:

    You’re probably not allowed to confirm this, but I’ll ask anyway: is there any truth to the rumours that Whidbey (and hence C# 2.0) is now delayed until early 2005?

    If it’s being delayed solely for synchronicity with SQL Server Yukon, please don’t – if the Framework, ASP.NET and Visual Studio are ready, please release them. IMO, the community that will be writing stored procedures as CLI components is a small proportion of the community as a whole.

  3. It seems to now be official that Whidbey has been delayed according to <a href="http://www.eweek.com/article2/0,1759,1546526,00.asp"&gt; this website </a>

  4. Steinar Herland says:

    If this is due to delays in Yukon, this is just sad. I could’t care less about when sql-server is released. (In relation to whidbey.) Some products don’t even use a db. Our products have to suport multiple databases and versions. Also, our customers certainly won’t upgrade to yukon the first day it is available. We (where I work) however, will release new versions of _our_ products when whidbey is out of the beta-phase. MS have just delayed our schedule due to a product our customers most probably won’t consider. Whoever it was who had the *insane* idea that we should wait for a upgrade of a _database_ to be able to use the latest and greatest IDE & runtime environment should have his/her brain checked. This is in deed sad news.

  5. I feel bad for guys like Eric and the rest of the developers at MS. It’s not their fault someone made this bone-headed decision. I think the really irritating part of the 2K5 fiasco is not that the software slipped – every experienced developer and PM knows that 75% of projects slip – it’s the characterization that *customers* supposedly want Whidbey to ship at the same time as Yukon. Come on. Puh-leaze. When will execs stop thinking they know what customers want and actually ASK? The severe backlash in the blogosphere since the announcement proves this. Google "Whidbey slip": 5810 results. Care to guess how many *customers* are saying, "Yep. I want to wait a year for a tool refresh, generics, refactoring, and a Microsoft IDE that produces xhtml."

  6. I can think of one thing that I would like to see added Post-Whidbey… actually I wish it was in Whidbey… const reference parameters!

    With the increase in components available … and the idea that we should be fine with black boxes… I want some safety when I pass a variable into a black box. I want to know that when a function returns, my variable didn’t change. I want the compiler watching my back… not just when I call a function, but when I write it. I like the idea that I cna declare my intention not to change a variable, and then allow the compiler to verify that fact to me. Call me crazy.

    Here is a more detailed blogpost I made on the subject. http://schweitn.blogspot.com/2004_02_01_schweitn_archive.html#107782132911035587

  7. If Edit and Continue were the only new feature added, I would be completely satisfied. :-)

  8. RichB says:

    > Refactoring rated higher than E&C

    I sometimes wonder who Microsoft ask for these opinions. I suspect it’s internal Microsoft developers and Wintellect/DevelopMentor trainers.

    With all due respect, these type of people are not your average C# programmer. In the 3.5 years I’ve been coding in C#, I’ve yet to work with anyone who wasn’t bothered about E&C.

    I can purchase an exceptionally good C# Refactoring tool from a 3rd party company, but I can’t buy C# E&C from a 3rd party. I don’t doubt that refactoring is good and a cool feature (I own a 3rd party C# refactoring tool) but E&C is unequivically more important.

    To quote Brian Harry talking about E&C:

    "We are going to ship this product and we will fix this, add this feature back the first thing after we ship v1."

    – August 2001

    Most developers I spoke to were a little upset by this, but could settle for a v1.1 product which had E&C. Sigh.

  9. Alexander Neumann says:

    What about non-null reference types?

    This MSR paper has detailed information:


  10. Eric Newton says:

    I would’ve voted for Edit/Continue because a good portion of the time I can make a small fix even with the Command Window to just fix that dumb little bug of setting something to 0 instead of 1 for example…

    And suspending .Net 2.0 for Yukon is just plain silly.

  11. Eric Newton says:

    Another thing, since supposedly E&C works in VB, why would it require so much effort to get C#’s since it most likely was more of a Runtime issue to relink and graft that code in memory in place of the old IL?

  12. MBA says:

    Helpful For MBA Fans.