Share via

You can't do Edit-and-Continue with Interop-debugging on.

  • Article

Somebody asked on the forums about Edit-and-Continue (EnC) in mixed mode. You can't use managed EnC with mixed-mode (interop) debugging enabled. This is a limitation of the CLR Debugging Services. Both Interop-debugging and EnC are complicated features; combining them would be a huge test-matrix and very costly. So if you have a C# and native C++ solution, your options are:

1. If you want to debug + edit just the C# code, you can use managed-only debugging.
2. If you want to debug + edit just the native C++ code, you can use native-only debugging.
3. If you want to debug both C# and native C++ code (but not edit), you can use interop-debugging.

Note there are no regressions here: VS6 only allowed you to do option 2, VS 2003 allowed you to do options 2 and 3; VS2005 allows all 3 options. 

See Steve's post on managed vs. native vs. interop debugging, and how to change that in VS.

Managed and native debugging have their own implementations of basically everything (stepping, callstacks, breakpoints, inspection). Interop-debugging glues these two worlds together. EnC is no different. Doing EnC in managed code is completely different than doing it in native code, and uses completely disjoint debugging functionality.  So while managed-EnC won't work under interop; a debugger could write native-EnC support that does (I don't know offhand whether VS allows native-enc or not).

What about MC++?
This is also interesting with MC++. If you compile C++ to IL, then it's managed code and needs the managed debugging services. If you compile C++ to native, then it's native code and uses the native debugging services. Since MC++ makes it very easy to compile C++ to both IL and native (and produce a mixed assembly), debugging MC++ generally defaults to interop-debugging.

Comments

  • Anonymous
    January 28, 2006
    Not only can you not use E&C in mixed mode, but in VB you can't even E!

    Until this is fixed I won't be able to use VS2005.

    Here's a bug report I filed:

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=554135f3-6974-4ed5-a86d-6a69ca861f6b

    As you see in the bug report, MS just dumped the issue without addressing it at all!
  • Anonymous
    January 30, 2006
    Michael - I just tried it out and I observe that same behavior, and with C# too.

    It looks like when mixed-mode debugging, all files (in both C# and VB) become read-only.

    1. I see in your link that you saw C# was working correctly?

    2. I'm curious - why is this blocking? Maybe we can find a workaround.

    3. Can you reactivate that bug report?

    FWIW, this is an issue with the debugger application, and not the underlying debugging APIs. Not that that makes you life any better....
    Practically, it means that this problem is from Visual Studio, not the CLR, and so other managed-debuggers could have it fixed.
  • Anonymous
    February 13, 2006
    In .Net 2.0, we wanted to focus managed Edit-And-Continue (EnC) resources on the core-scenarios so that...
  • Anonymous
    February 22, 2006
    Mike,

    I just unfortunately discovered that if you add a setup and deployment project to an existing VB project, Edit and Continue stops working with the "Cannot currently modify the text in this editor. It is read-only." message. I tried removing the setup project but apparently, once the files are set to read-only, I can't figure out a way to reset them short of moving all the files to a new folder, which works. Not good!

    David
  • Anonymous
    February 22, 2006
    David - I just tried it out and I was still able to do EnC in my VB project, even after I added the setup + deployment project.

    Can you provide more detailed repro steps and we can look further?

    Thanks!
  • Anonymous
    January 09, 2007
    I've had a growing number of people inquire about how to write an interop-debugger with ICorDebug. My