We currently ship a command line debugger in the SDK, Cordbg.exe. It's implemented in unmanaged C++. In v2.0, our debugger test team also started developing their own command line debugger, MDbg, written in C# and harnessing the awesome power of managed code.
We don't want to maintain two command line debuggers. We'd strongly prefer to deprecate Cordbg and just go with MDbg. Thus we can redirect our efforts from Cordbg into the actual ICorDebug interface, which benefits all consumers (including Visual Studio and any third party tools).
Unfortunately, MDbg has a pretty different syntax than Cordbg and so we don't want to totally break people depending on Cordbg.
We're considering the follow plan. If you think this plan will cause you grief, please reply to this post and let us know.
a. The CLR wins - we only have to maintain a single command-line debugger (Mdbg), which we already have to maintain for our testing purposes anyways. We can free up all resources spent on Cordbg.
b. All ICorDebug consumers win –. We can focus our resources on the real product. Also, people depending on Cordbg are not totally broken.
3) As part of this, we're thinking of not including the following Cordbg commands in the emulation layer because we consider them to be sufficiently obscure that nobody actually uses them:
a. conn[ect]- Connect to a remote device
b. regd[efault] - Change the JIT debugger
c. newobjnc - Create a new object via function evaluation, no constructor
d. > - Write commands to a file (this doesn’t seem to work as people expect anyways)
e. uw[here], ut[hreads], uc[lear] – These are all the interop-debugging test commands that and Cordbg is not officially an interop-debugger.
f. wt - Track native instruction count and display call tree
g. wr[itememory] - Write memory to target process
4) Cordbg's v2.0 beta introduced several new commands. We'd only include the following in the emulation layer:
a. attachn[ame] -attach to a process by name.
b. int[ercept] - intercept a managed exception (new feature in whidbey)
c. # - comment command (very useful for scripts).
5) Other inspection information (such as getting a function's IL-->Native map, or IL debugging) would be available in MDbg via extensions.
6) Cordbg’s fate on other platforms (like Rotor and Compact Frameworks) is still up in the air. Whatever we do, we’ll keep some command line debugger for them. Maybe those platforms will continue to use the native C++ Cordbg. Maybe we’ll get MDbg running on them (that’s a little harder since Rotor doesn’t support COM-interop)
Let me repeat, we’re just considering this plan and it’s all tentative. No commitments. If this all works, we'd expect the vasst majority of people to not notice any change in cordbg and not realize that they're actually using MDbg in an emulation mode. I’d love your feedback about what you think (just post feedback to this blog article).