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 S.R.Emit. Am I correct that Cecil will be powerful assembly reading and writing library? 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? David
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
