[Mono-devel-list] Edit and Continue
dsrbecky at post.cz
Thu Aug 4 13:34:51 EDT 2005
Thanks for the reply,
Some people at Microsoft were very kind and have send me their, at the
moment, internal Edit and Continue documentation. I will not repay their
kindness by publishing these documents on public maillist, but if anyone
is interested please let me know and I will send the documentation to you.
ILAsm v2.0 is able to produce metadata deltas which we can use to
further check the implementation.
I have written a debugging library that uses MS debugging API and which
can apply metadata and il deltas to running programs. (So far, it was
successfully test on the output of ildasm)
Thanks for help,
Paolo Molaro wrote:
> On 08/03/05 David Srbecky wrote:
>>My name is David Srbecky and I am working on SharpDevelop 2.0 debugger.
>>The debugger is getting nearly finished, but it is still missing one
>>'cool' feature - edit and continue. The support for Edit and Continue
>>(EnC) from the side of Microsoft runtime is good enough, but there is no
>>support at all from the compiler side - all the functionality is private
>>and mostly part of VS. This effectively means that to support EnC, I
>>must write my own compiler. I would never try to that, but fortunately
>>there is mono to save the day. I would like to use the mono compiler to
>>produce the necessary deltas, which I must feed to MS runtime. The
>>problem is the I know neither the internals of mono compiler nor the
>>internals of System.Reflection.Emit and implementing support of EnC
>>would be a tedious or impossible task for me.
> There is no documentation about what the MS runtime expects in the
> edit and continue metadata tables. You could get someone living in a
> free country to reverse engineer the metadata tables and write a spec.
> Then we could start to see if the spec is easily implementable in
> mono's reflection.emit code.
> My guess is that it would be quite complex to implement _and_ make
> it work with the MS runtime.
> If people find the edit&continue feature useful, I suggest
> implementing it in mono for mono (this of course requires people to
> help the debugger folks first, though).
More information about the Mono-devel-list