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.