[Mono-dev] Re: Edit and Continue
lupus at ximian.com
Tue Aug 16 12:04:27 EDT 2005
On 08/16/05 David Srbecky wrote:
> schoolwork, I will do some research, produce a battle plan and I will
> come back :-)
> Do you mean that Cecil can not access the runtime similarly as
> Reflection.Emit? Ok, got it.
It can access it, but only through a very coarse mechanism: assembly
> > 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?
Some managed and some unmanaged.
> Isn't it better to use managed Cecil in S.R.Emit do the reading and
> writing of assemblies?
The runtime needs to be able to read assemblies before executing them,
so this code must be unmanaged. Having a second copy of the code in
managed form would be just a huge and useless resource waste.
(Yes, I know about jikes-rvm and I also know about the orrible
maintainance issues they have: they can afford it because it's a
As for writing, re.emit is not obly concerned with writing assemblies,
but also with creating and executing code in memory: this is only
possible with a tight integration with the unmanaged runtime. Some parts
of Re.Emit are already managed code and I guess some small parts of
unamanged code will be moved to managed sometimes in the future.
But this won't involve Cecil in any way: the unmanaged code amounts to
about 40 KB of x86 binary and the Cecil assembly is 300+ KB of IL.
We can't afford to use that much code to implement one of the
fundamental runtime features.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list