When can't you do Edit-And-Continue?
In .Net 2.0, we wanted to focus managed Edit-And-Continue (EnC) resources on the core-scenarios so that we could make those as good as possible. One significant resource was testing: if you think about what it means to really test EnC, you can probably appreciate our desire to reduce the test matrix.
Practically, this means that you can't EnC (for managed-code) in certain non-core scenarios:
| You can't EnC ... |
Why? |
| ...for non-x86. |
EnC does some very low-level things that are pretty OS-specific and so limiting to a single platform was primarily a resource-constraint. Future CLRs will no doubt expand this.
Our porting effort also started from scratch in V2, and so all the rest of the debugging services had to be ported too, so we already had a very large item here.
Also, we believe the biggest scenarios for EnC would revolve around pure-IL apps that allow people to at least develop in x86. There's a workaround in such cases: on a 64-bit machine, you can launch a pure-IL app as 32-bit app in the WOW, and then do EnC on it. |
| ... if a profiler is attached. |
There are some collisions between these features and we didn't see this as a core enough scenario to spend the resources working those out. For example, the profiler interfaces don't expose recognizing the same method EnC-ed multiple times. |
| ... dynamic code or in-memory modules (which I mentioned previously). |
See here. Quick summary is that this wasn't a core scenario; and there seemed to be enough workaround options (such as re-emitting the code). |
| ... modules loaded before you attached. Although you can attach, load new modules, and EnC those. (This is what VSHost will actually do). |
EnC requires special code-gen flags, which have to be passed before the module is jitted.
Pass CORDEBUG_JIT_ENABLE_ENC (from the CorDebugJitCompilerFlags enum) to ICorDebugModule2 ::SetJitCompilerFlags. |
| ... if you're interop-debugging. |
Interop-debugging does some crazy things that conflict with the crazy things EnC does. While these could be made to work in theory, it wasn't a core scenario to justify both the development and test costs. |
| ... code loaded by ngen |
This is related to needing special codegen. This would also introduce many corner cases. For example, calls to ngen code may be optimized such that EnC can't update them to point to the new version of the method. Sure, we could workaround things like that, but it would just be more complexity in EnC. |
| ... mscorlib.dll. |
We really didn't want people trying to change System.Object. |
These are all limitations of the CLR, not Visual Studio, which means if a 3rd-party debugger adds EnC, they'll have the same restrictions. In all cases, we were felt happy that the the cost of enabling each case was better spent making the core-scenarios stronger.
