The current plan is that Visual C# will not support Edit-and-Continue in the
Whidbey timeframe.

We asked the C# Customer Council if they preferred more and better
refactoring, or Edit-and-Continue. They were very clear that they would
prefer better refactoring, so we went down that path.

It's true that the runtime supports EnC.  The question is, does the TOOL
support it?   and in Whidbey, the plan is the VB tool will support EnC,
while the VC# will offer better refactoring.  This is one example of the
greater distinction between the tools planned in the Whidbey timeframe.

This is what we mean when in the roadmap discussion we say
   "In Whidbey, Microsoft will expand upon the unique strengths of Visual
Basic,
   Visual C++, Visual C#, and Visual J# to provide a rich language offering
for
   developing a range of robust software in minimal time."

http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#whidbey

Now I understand the reaction that some will have.  I am like you all, I
want all the features, in my preferred language and tool.  EnC is a
nice-to-have feature, it's valuable.  And believe me the product team at
Microsoft would like to deliver "everything".  But it becomes a challenge to
fit the features in the schedule.  To strike the right balance, we engage
with customer councils, very early on, to help define the way the vNext
products ought to look.  We place A LOT of weight on what they have to say -
they steer the boat.  And this is the direction they told us to take.

-Dino
<Microsoft/>