Will "Edit and Continue" work on 64 bit OS under Visual Studio 2010?

Question

I know there is a workaround to force compilation to 32-bit and then debug it under WoW64, but with everything going 64 bit is there any change of us seeing native support for Edit and Continue on 64 bit Vista / Windows 7 using Visual Studio 2010 & the .NET 4.0 CLR ?

---

Answer 1

I Haven't tried with any other languages then C# but its finally wokring in beta 1 :)

Answer 2

Okay I'll take that back they cheated and made the default platform x86 instead of Any CPU what it used to be, c'mon microsoft stop cutting corners!

Answer 3

Okay I'll take that back they cheated and made the default platform x86 instead of Any CPU what it used to be, c'mon microsoft stop cutting corners!

The default platform is x86?  That sounds incredible.  Are you sure that's not just a bug in the beta?

Answer 4

And still not adressed in beta 2, well it has only been 5 years since the issue was first reported silly of us to expect they could actually fix it in 5 years..

but joking aside, what the h*ll Microsoft! windows server 2008 R2 doesn't even ship in x86 flavours anymore! and somehow its not a priority to get developers up and running with the same tools they know and love from x86 in the x64 world as quickly as you can?!  Why is the OS group going all X64 and is the developer group treating x64 as a thrid class citizen?

I'm confused!

Answer 5

Turns out that not only Edit & Continue won't work for x64 executables, but the new key feature "IntelliTrace" (historical debugging) isn't fully supported in 64-bit mode either.  Boo!

From the relevant MSDN page:
http://msdn.microsoft.com/en-us/library/dd264915(VS.100).aspx

"IntelliTrace supports post-crash debugging of 64-bit applications through trace debugginglog files created by IntelliTrace. It does not support debugging 64-bit applications launched from Visual Studio."

I did find a blog post by Rick Byers explaining why VS2010 changed the default from AnyCPU to x86:
http://blogs.msdn.com/rmbyers/archive/2009/06/08/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx

And in related news, Rico Mariani has written a post explaining why VS2010 itself is still a 32-bit application:
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx

I don't care that much whether VS2010 is 32 or 64 bits but the feature disparity has to go, and switching back from AnyCPU to x86 at this point is just ill-advised IMO.  It's going to make matters worse at a time when developers are coming to grips with 64-bit development.

Answer 6

I would assume this also means that edit and continue doesn't work for LINQ either??? it's a serious productivity killer not having this just to debug a query!  This is a must have! I can live with setting debug mode to x86 for edit and continue, I haven't seen any differences between the two, but LINQ not working??? common! This needs to be a requirement for release.... oh and linq in the immediate window!

All I'm asking is for a less buggy VS.net 2008 with edit and continue that works in all cases..... oh and silverlight where there are actually data components that work. Everything else is candy to me.... and it appears that none of it works still!

Answer 7

Rick's blog explains the rationale behind the reaons why it is what it is.  The takeaway is that the Connect issue(s) requesting EnC support in x64 have very few votes.  So (based upon Connect) it isn't important to a lot of people.  Rick's post does clearly explain why the default was changed (only for EXEs though - it was a bug in B1 that caused all projects to default).  Only EXEs default to x86.  DLLs remain AnyCPU.  It is important to remember that a x86 program runs just fine under x64 so it isn't like you have to build multiple versions of your app.  You only need an x64 version when you need the featureset of an x64 process (which isn't common in most industries).  Honestly how many commercial apps really need more than 4GB of memory? 

I do x64 work and I have to say I never use EnC (for any platform).  It hasn't stopped me from developing commercial-ready apps.  So I don't believe that MS is trying to stall x64 development.  Some things are just harder to implement correctly given the time constraints.  Would I have preferred to have EnC in x64 over, say, historical debugging?  Probably but evidentally the majority believed otherwise.  Would I prefer EnC over the revamped Intellisense?  No chance.  Remember that EnC wasn't even supported in the initial release of .NET (at least C#) and yet .NET development was fine.

A final thing to keep in mind is that EnC requires work on both the CLR and the debugger.  This is two separate teams, each with their own priority list and schedule.  I've heard rumors that the debugger can easily be updated (or already is) to support EnC x64 but the CLR is not (or vice versa).  Whether that is true or not I don't know.  Nevertheless you have to have both before it'll work.  Unfortunately the x64 architecture is radically different from x86 (which is a good thing) so some things just don't work.  For example the x64 debugger silently eats unhandled exceptions that occur when a form loads.  I don't think this is fixed in VS2010 because of the problems associated with handling exception in x64.  I'd put this one at a higher priority that EnC just because more people will run into it.  IMHO.

Michael Taylor - 10/22/09
http://p3net.mvps.org

Answer 8

John you must keep in mind that VS is language-agnostic.  LINQ is implemented by the language you use, not by the IDE or the debuggers (which don't even care about the language).  The immediate window is implemented by the IDE.  You can test LINQ-style queries in the IW but you have to do the exact same thing that the compiler does and that is converting from the SQL-style syntax to the underlying methods.  At the end of the day that is all the debugger runs anyway.  What would be an interesting addon to VS would be a LINQ query window where you could write LINQ queries and then view the results.  This would require that the window somehow determine what version of LINQ you wanted to use (because VB and C# don't support the same features) and then compile and run the code.  Getting contextual information in would be a little difficult but otherwise it wouldn't be that bad to implement. 

As for SL, 2010 has (supposedly) done a lot of work to better integrate SL and ASP.NET MVC.  Have you tried the latest B2?  I don't use SL so I can't commit if it is any better.  But if you do find issues or want additional features then you need to submit them to Connect and then get votes for them.  That is predominantly how things get prioritized for the next release.

Michael Taylor - 10/22/09
http://p3net.mvps.org

Answer 9

I agree weither visual studio itself is x64 ,x86 or is running magic pixie dust extracted from unicorn tears doesn't intrest me at all but atleast make the 'standard' debugging scenario's available for the platforms you say are "first-class citizen"

favorite quote from the page you linked

"On the CLR team, we consider x64 to be a first-class citizen whenever we add new functionality, but the reality is that we've got a complicated code-base (eg. completely separate 32-bit and 64-bit JIT compilers) and we sometimes have to make trade-offs (for example, adding 64-bit EnC would have been a very significant cost to the JIT team, and we decided that their time was better spent on higher priority features)."

"we really care!! but its really hard soooo when prettymuch anything else comes by then we drop it immedeatly and do something else instead)"

Don't get me wrong I was ok with waiting a bit for this feature in 2004-2005 x64 didn't have nearly as much momentum as it has now, that the feature was missing in 2008 was unfortunate to say the least but hey they'll fix it in the next version. That they now are planning to ship 2010 with completly crippled x64 feature support (like you said IntelliTrace didn't get any x64 loving either) is just blowing my brains. Sure they have limited resources, but really lets assume the next version is another 2-3 years away (2012/2013?) making it 7-8 *years* for something that should have been there from the start is *NOT* a resource problem or "sometimes" having to make a trade off , I'm at loss for words to describe what it would be though.

wow microsoft...just wow....   

Answer 10

... and even then linq, the defacto way that ms wants us to program, blocks EnC entirely!!!! This feature is all but a dead duck at this point! They might as well give up and pull it again.

Either that or fix it and make it work! Right now unless you're writting old code with old programming methodoligies you're screwed.  MS, if you're going to add a new feature, you have to commit to having EnC for it before release. It should be a standing requirement. If it takes 2 more months to get it out the door, so be it but you can't leave such a hugely effective tool (especially for debugging and testing database queries linq or otherwise) completely crippled!

Answer 11

I'm not trying to be evil here but in regards to EnC there doesn't seem to be a lot of folks demanding it.  It technically isn't needed to do x64 development although it might be a nice to have so it isn't a feature that makes VS mute for x64 development. 

There are several requests for it on Connect but the highest only had 13 people.  Of course if you need the feature before you consider x64 debugging to be doable then the priority for this is just above "read my mind and write my code for me" but nevertheless standard PM guidelines say that if a feature is going to require X resources for Y days to satisfy a handfull of folks while another feature requires similar (or less) resources and satisfies more then the priority becomes obvious.  In fact I've seen several folks from MS blog about this and then read comments from folks saying not to waste time on it because feature Z is more important to them. 

It isn't (nor will it be) be in VS2010.  The odds that it would be added into a SP is next to nil given that it requires a CLR change as well.  Your best bet is VS.Next.  However to ensure that it gets into the next release those folks who really want this feature need to get onto Connect and make sure the votes get in for the feature.  Otherwise it'll fall of the list again.  A good way to do that is submit the Connect issue (if one isn't already open again) and then attach a link to this (and other) forum postings and get all interested parties to vote on it.  If somebody submits the Connect issue then I'll vote on it just to help get it moving along because I realize a lot of people consider it a deal breaker.  But personally I could care less about it.  I never had much luck with EnC in its infant days and it has basically turned me off to it since.

Michael Taylor - 10/22/09
http://p3net.mvps.org

Answer 12

Ok.... x86 by default I'll live with. But I can't use Linq properly until EnC works because it kills my productivity. 99% of the time that I spend is either debuggin t-sql commands or debugging linq commands that do the same with EF.  If you triple that time because i have to restart, recreate the conditions of the test to test every time I change one join or add a field or whatever, you've created a massive reason not to use EF and linq which I don't want to have happen because I firmly believe that Linq is the future of all programming so I want to use it.

Answer 13

I'm not trying to be evil here but in regards to EnC there doesn't seem to be a lot of folks demanding it.  It technically isn't needed to do x64 development although it might be a nice to have so it isn't a feature that makes VS mute for x64 development. 

There are several requests for it on Connect but the highest only had 13 people.

So people need to be signing up to Connect and posting requests before it will be implemented? :S Broken debugging makes it 'mute' for my purposes. With VS2005 we copped it on the chin as x64 was still 'relatively' new. With VS2008 it was extremely frustrating but again copped it on the chin. With VS2010 if proper x64 support isn't provided it will be the final straw amidst an ever-growing haystack (ASP.NET MVC being the other major recent addition) which prompts us to start investing more heavily in truly cross-platform and open alternatives. As I've posted in other forums, MS tech is great when it works but I think they are victims of their own size and ambition in many ways and the expense (on all levels from ongoing developer training and certification to end-user licensing) of supporting MS technologies is feeling less worth while as time (and each product cycle) rolls on.

Answer 14

I'm not trying to be evil here but in regards to EnC there doesn't seem to be a lot of folks demanding it.  It technically isn't needed to do x64 development although it might be a nice to have so it isn't a feature that makes VS mute for x64 development. 

No offense meant but that is not really a realistic argument for anyone developing commercial software. We currently develop 32 and 64 bit libraries. However for future versions we only require 64 bit. Not having 64 bit EnC means maintaining 32 bit continuous integration builds, 32 bit nightly builds, 32 bit release builds, 32 bit installers, 32 bit versions of unmanaged dlls, just to be able to debug properly!!