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!!

Answer 15

I'm also baffled and amazed that EnC isn't available on x64.  I'm currently developing a plugin for a third-party 64bit application, so there's no way to debug code as an x86 target.  For years I've been spreading love for EnC - it was the standout feature that separated VC from other dev environments for me, I totally rely on it all the time.  It saves a _huge_ amount of time, especially when coding (for) apps that take forever to start up.  I can't imagine why people wouldn't be screaming for it on x64?? 

And that it's still not in 2010 is just an outrage!

Answer 16

I'm absolutely in the very same situation. I develope plug-ins for CAD, almost all of my users run on x64 and I'm stuck with a 32bit workstation.
Fortunately there are very little differences between the two platforms, but you never know, right know I'm simply unable to debug on the real thing.

I'm surprised to read "Honestly how many commercial apps really need more than 4GB of memory?" from an MVP.
Are you missing something? My (professional) world is CAD and today even AutoCAD barely run with the 2GB application limit, not to speak of more demanding application like solid modeler or structural analisys... just add a couple of Excel spreadsheets and the game is over.

I hope Microsoft will go full 64bit soon. And I believe is already too late...

Answer 17

You're confused I believe.  The bitness of your development machine is not a factor for EnC.  You can use EnC on a x64 development machine.  I do it myself.  You cannot currently use EnC with an x64-build of your program.  They are different beasts.  VS is an x86 program so whether you are running an x86 or x64 dev box makes little difference - it still runs in x86 mode.  However the debugger can debug x64 programs only if you're running on an x64 machine.  So in your scenario you can run an x64 dev machine (like your clients).  You can debug using x64 if you don't want EnC support.  If you do want it then you'll need to switch back to x86 builds.

CAD programs are one of a handful of app types that might require more than 4GB of memory but they are in the minority.  Most folks have never seen or used a CAD program unless they are in the business.  There are quite a few "niche" apps that are like that.  Of course if you develop or use these types of apps then their needs are paramount and things like web services, clouds and WWF are unimportant but unfortunately MS targets the areas that get the most bang for their buck (as do we all).

Most apps are standard Windows clients, smart clients or web apps - none of which require x64 processing at this point.  Server apps, heavy data apps and mathematically intensive apps are the only ones that currently truly benefit from x64 OSes.  If it wasn't for the 4GB limit (which can be extended in x86 BTW) then I doubt we'd even be seeing x64 starting to pick up speed.  Today only servers are really benefiting from x64 power and that is more because of the extended memory than anything.

We are at the threshold right now where the # of x64 client machines are starting to catch up and exceed those for x86.  OEMs have just recently (read in the last year or so) started shipping home computers as x64.  Windows Server is x64 only and I predict that the client OS will become x64-only in the next 2 releases.  128-bit is on the horizon.  The transition from 32 to 64 has been more gradual than from 16 to 32 simply because x86 apps are coded and act similar under x64 whereas Win16 apps were radically different from Win32 apps. 

x64 EnC is inevitable.  We will one day be doing x64 development, glad we moved away from x86 and wondering why some feature we need isn't implemented in the 128-bit debugger yet.  It's a matter of cycles.  Nevertheless go to the Connect site and vote for the item that requests EnC support in x64.  Until it gets enough votes it won't be implemented.  Historically speaking MS is more interested in adding new features than updating existing code to support something new.  It is only after enough people complain in an organized manner that existing code is changed.  IMHO

Michael Taylor - 2/22/2010
http://msmvps.com/blogs/p3net

Answer 18

If 64-bit EnC were inevitable, then it would be here by now.  It's been a requested feature since VS 2005.  Suggesting that we "up-vote" bug reports or feature suggestions on connect is unhelpful as Microsoft closes those with meaningless resolutions before they have any real chance at being upvoted.  See these three issues for good examples.

The favored blog post dealing with x64 EnC seems to be this one .  According to the post, the major stumbling block to supporting 64-bit EnC is developing and maintaining both a 64-bit and a 32-bit code base for debugging.  Rather than investing the effort in getting the 64-bit debugger up to speed, though, Microsoft is glomming more enormous features onto the 32-bit debugger (IntelliTrace), which can only further delay the "inevitable" arrival of 64-bit EnC.

If Microsoft truly believes that 64-bit OSs were the way of the future, then why does it keep improving the x86 tool chain while neglecting the x64 tool chain?  The x64 tool chain in VS 2010 is, in many important ways, less capable than the x86 tool chain in VS 2005 was.  For those of us working in "niche" fields that actually have to develop x64 software, it's hard to feel like you're developing software for the "operating system of the future" when the tools you have to use to do so feel crippled and outdated.  It's time for Microsoft to really step up and support x64 rather than treating it as some kind of unwanted burden that can be dealt with in "the next release."  5 years and 3 releases is long enough to wait.

Answer 19

All this talk of "you only need to program for x64 if your process needs more RAM" is wrong. If you are writing database software and you need to talk to a 64-bit ODBC driver or OLE DB Provider, then the process needs to be 64-bit. My company provides both 32-bit and 64-bit versions of these drivers, so AnyCPU makes a lot of sense for me.

Answer 20

Please add your vote on the link below to have Edit and Continue on x64:

https://connect.microsoft.com/VisualStudio/feedback/details/661089/need-c-edit-and-continue-on-x64-native-mode

 

Answer 21

Hey how else are they going to keep up the 'oh we didn't do that cause nobody asked for it" thing :)

Answer 22

There is no solution.  EnC doesn't work under x64 builds.  You either have to do without it to test x64 builds or compile and test under x86.  Honestly in managed code bitness of the code is almost never an issue.  The only case I can think of where it would even start to matter is when working with pointers (such as interop) or testing x64 native components (like COM).  Until the CLR and Windows are modified to support this it won't work and that isn't happening until at least V.Next.  From what the CLR folks said it is a major undertaking.  I suspect Intellitrace relies on EnC to rewrite code so it likely won't work until EnC does.  The IT folks would have to clarify the rationale for that though.

If this feature is important to you then go vote for it at Connect.  Currently there aren't enough votes for this feature to make it worth the development effort.  It will eventually get here but it hasn't been a priority up til now.  We'll see in v.Next.

Michael Taylor - 10/15/2010
http://msmvps.com/blogs/p3net

Answer 23

One minor comment about another post in this thread -- I've heard it from a good source that IntelliTrace will support 64-bit binaries in Service Pack 1 for Visual Studio 2010, although I don't know when that will be released.

Answer 24

There is no solution.  EnC doesn't work under x64 builds.  You either have to do without it to test x64 builds or compile and test under x86.  Honestly in managed code bitness of the code is almost never an issue.  The only case I can think of where it would even start to matter is when working with pointers (such as interop) or testing x64 native components (like COM).  Until the CLR and Windows are modified to support this it won't work and that isn't happening until at least V.Next.  From what the CLR folks said it is a major undertaking.  I suspect Intellitrace relies on EnC to rewrite code so it likely won't work until EnC does.  The IT folks would have to clarify the rationale for that though.

If this feature is important to you then go vote for it at Connect.  Currently there aren't enough votes for this feature to make it worth the development effort.  It will eventually get here but it hasn't been a priority up til now.  We'll see in v.Next.

Michael Taylor - 10/15/2010
http://msmvps.com/blogs/p3net

So how many votes does a feature need to make it "worth the dev effort"? https://connect.microsoft.com/VisualStudio/feedback/details/559582/need-c-edit-and-continue-on-x64-native-mode already has 130 upvotes, does it need a thousand? 10,000? Because considering how few people use Connect, I'd say 130 is a lot.

Answer 25

Coodadtx, Verna is a spam bot. Look at the post's HTML, there is a hidden seo link added to the last word "64-bit" in the quoted text.

---

---

The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
Visual C++ MVP

Answer 26

Still not working on visual 2012

Answer 27

This https://connect.microsoft.com/VisualStudio/feedback/details/636359/edit-and-continue-for-64-bit-applications seems to be the latest incarnation of this issue on Connect. The author lists five tickets for this (including the one above. Jose Luu has added a screenshot of his (sixth) issue which has 314 up-votes. (Click on expand to see this.) Only the last two tickets still seem to exist (but you can't vote for them anymore); they have 17 and 10 votes respectively.

341 up-votes (plus the ones on the other tickets that are no longer there, so we don't know how many votes they got) makes this far and away the second highest voted feature ever. (Go here and click on "Most Voted".) Not that you'd know that from the list as the votes are spread over a load of mostly closed tickets.

And apparently it's still not in VS2012. This is just getting ridiculous.

Answer 28

Ridiculous doesn't even cover it.  But here's one you can actually vote on, DO IT NOW:

https://connect.microsoft.com/VisualStudio/feedback/details/736684/edit-and-continue-is-not-supported-when-debugging-a-64-bit-application