Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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