Partager via


ICorDebug, Edit-and-Continue, and C#

In case anybody missed it, VS 2005 C# is going support Edit-and-Continue! (See announcement, and some follow up posts by the C# team from Andy and Steve).

 

The CLR is a language-neutral platform. So naturally, our debugging API (ICorDebug) operates at the IL level so that it can be language-neutral as well. The Edit-and-Continue support in the debugging API is language-neutral, though it was mainly designed to ensure that key VB scenarios worked.   

 

In theory, any 3rd party could write their own managed debugger and support EnC for their own languages ([Update]: see here for how a 3rd-party can support EnC).  The C# team put this to the test because they did EnC without any additional modifications to ICorDebug.

Comments

  • Anonymous
    October 17, 2004
    I encourage you (and you colleagues) to write articles about exactly how "any 3rd party could write and support EnC". Perhaps a step-by-step covering each main idea up to and including supports stepping and watchpoints.

    I, for one, would love to see such content.

    (Perhaps this content would even make a good candidate for a follow-on book for "Build Your Own .NET Language and Compiler" in collaboration with it's author, Edward G. Nilges.
  • Anonymous
    October 17, 2004
    [ Pardon the earlier typos. I meant "your colleagues" and "including support for". I must be tired. 6:18 AM here. ]
  • Anonymous
    October 17, 2004
    BillT - are you thinking of writing your own enc-cabable debugger?

    I'll add it to my blog todo list. Thanks for the suggestions.

    FWIW, MDbg has a very primitive demo of the interfaces, but we recognize it's not nearly enough to infer a complete solution.
  • Anonymous
    October 17, 2004
    The comment has been removed
  • Anonymous
    October 17, 2004
    Kudos indeed to the C# team!
    It was practically no extra work from the CLR end (since we're language neutral), but I need to point out that the language-services actually did have a bunch of work needed to make a language EnC-capable.
  • Anonymous
    October 27, 2004
    Well, if parsing front end is important, then my book is useful. I suppose that in debugging scenarios the debugger would need to parse complex expressions, but my book intentionally skimps on code generation.

    Its primary mission is to show that there's a body of well-established theory out there which programmers can use in the front end of any parser, and that they don't have to either develop their own theory or use a "tool" which is hard to manage because it does its own thing.

    But to work with EnC you need depth also in CLR and code generation, to which only a chapter is devoted in my book.
  • Anonymous
    October 28, 2004
    The comment has been removed
  • Anonymous
    August 16, 2005
    Native-only debugging allows you to debug child processes. In other words, you can debug process A, and...
  • Anonymous
    August 18, 2005
    Native-only debugging allows you to debug child processes. In other words, you can debug process A, and...
  • Anonymous
    August 18, 2005
    Native-only debugging allows you to debug child processes. In other words, you can debug process A, and...
  • Anonymous
    March 28, 2006
    Here are some random software things I use that really change how I work.

    OneNote: Word is not a...
  • Anonymous
    July 13, 2006
    PingBack from http://blogs.msdn.com/jmstall/archive/2005/01/04/346641.aspx