[Mono-dev] Re: Edit and Continue
dsrbecky at gmail.com
Tue Aug 16 10:44:41 EDT 2005
Paolo Molaro wrote:
> On 08/16/05 David Srbecky wrote:
>>Paolo Molaro wrote:
>>>What if you just recompile the assembly and develop an assembly diff
>>>tool? In a few months the Cecil library may be able to allow this.
>>I been suggested this many times, but the problem is that it is way too
>>slow. My target for application of EnC is < 100ms.
> Ok, then you might want to provide a detailed plan on how you want to
> implement this and maybe prototype the mcs support first.
To create detailed implementation plan, I must first find out how the
whole mcs and Reflection.Emit works. I somehow hoped that I will get
anyway with that, but it doesn't seem likely. After all, I must admit
that I am interested in the code anyway - so when I finish all my
schoolwork, I will do some research, produce a battle plan and I will
come back :-)
>>The Cecil: Am I correct that System.Reflection.Emit will be rewritten to
>>use Cecil when Cecil is finished? I think, this will be the right time
> There is some overlap between the two, but while re.emit can be
> extended to do what Cecil does (though at this time it does more,
> anyway), the reverse will never be true, because re.emit is a runtime
> feature, not a library and hence can, for example, create types and
> methods that the runtime can readily execute (mentioning AppDomain.Load
> (byte raw_data) at this point will make you lose bonus points).
Do you mean that Cecil can not access the runtime similarly as
Reflection.Emit? Ok, got it.
> Hope this helps to understand where Cecil and re.emit fits in.
Thank you very much, it help me to see the differences between Cecil and
S.R.Emit, however I still do not understand why you do not use Cecil in
Am I correct that Cecil will be powerful assembly reading and writing
And S.R.Emit needs, among other things, read and write libraries. Right?
S.R.Emit does that using unmanaged code now. Right?
Isn't it better to use managed Cecil in S.R.Emit do the reading and
writing of assemblies?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050816/02b9a157/attachment.bin
More information about the Mono-devel-list