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. 

Comments (8)

  1. Leea says:

    One restriction with E&C that gets me loads of times is:

    "Modifying a ‘method’ which contains an anonymous method will prevent the debug session from continuing while Edit and Continue is enabled."

    Also whilst in an anonymous delegate E&C doesn’t work.

    Regards

    Lee

  2. SameerV says:

    I wish core-dump debugging for Managed applications was included in VS 2005.

    Not that I don’t use E&C. But as a developer(personally) I value the ability to debug mini-dumps(generated on Customer’s machine) more than some features added in VS 2005.

    I think, I should stop moaning and get used to SOS and wait for VS Orcas.

    Regards

    Sameer

  3. V2 CLR added support for 64-bit (amd64 and ia64), and that includes managed-debugging support. So a 64-bit…

  4. In case you haven’t already heard from every other blogger (like Shawn, JasonZ and Brad) , V2.0 of the…

  5. David Srbecky says:

    A random EnC question:

    Can a EnC capable compiler work on top of System.Refletion.Emit? (ie. If an existing compiler is to be extended to support EnC, does it have to be rewritten to use the unmanaged emitting interface?)

  6. You can debug ngen (aka prejitted) code from VS2005 and also have the VS2005 IDE launch ngenned code.

  7. [Nacsa Sándor, 2009. január 20. – február 12.] Komplett fejlesztő környezet Windows kliens és web alkalmazások