Ich erhalte die Meldung "Änderungen an 64-bit-Anwendungen sind nicht zulässig sobald" ich "just in time" Änderungen machen möchte während die Anwendung unterbrochen ist. (Pause)
Mich interessiert hierbei der technische Aspekt. Warum sind "just in time" Änderungen bei 32 BIT erlaubt und bei 64 BIT nicht?
(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
Diese Aussage im gleichen Text ist noch interessant:
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)
Von Microsoft am 16.12.2008 um 19:59 bereitgestellt Hi ...,
Thanks for the feedback. We certainly appreciate it. You're hunch is correct that this isn't enabled in Visual Studio because the underlying support is not in the 64-bit version of the CLR.
We do have plans to do this feature in a future release of the CLR, but unfortunately it will not be available in our next major release, V4. Doing the work actually requires a fair amount of changes in a number of subsystems and we prioritized other V4 feautures higher (mainly because we felt there is a somewhat-reasonable workaround for this). For the time being, you'll still need to work around the issue (where you can) by running your app in 32-bit mode when you need to debug/EnC. I realize that's not possible in all cases and hope that it doesn't affect you too greatly.
I'm going to resolve this "won't fix" but that is merely to reflect the status for our upcoming release. Rest assured this feature is in our list of future work items and we'll be working to understand where we can fit this in our schedule.
If you have any additional questions or concerns related to this, please feel free to re-activate this bug.
Die Aussage Deiner Antwort auf meine Frage "Änderungen an 64-bit-Anwendungen sind nicht zulässig?" ist: "support is not in the 64-bit version of the CLR" das ist leide nicht sehr erhellend... Vielleicht hat noch jemand mehr Informationen?
Microsft hat einfach andere Prioritäten: http://blogs.msdn.com/b/rmbyers/archive/2009/06/08/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx