[Mono-dev] Re: Edit and Continue

Paolo Molaro lupus at ximian.com
Tue Aug 16 07:30:48 EDT 2005

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.

> 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

No, Cecil will never be used to implement re.emit: they do different
things. Cecil just writes an assembly file to disk and it needs
assembly references to work. Reflection.Emit deals with assemblies and
types in memory (though it also happens to be able to save them to
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).

Here are a few scenarios where Cecil or re.emit are the right tool
for the job (once Cecil is actually complete and working):
1) creating broken PE files to exercise the error paths in the runtime:
definitely use Cecil (we don't want to allow re.emit to create
arbitraryly broken images)
2) creating IL code analyzers, batch assembly rewriting tools: Cecil
(the read side of reflection is at fault here: it has many limitations
which we're too lazy to address now, the 2.0 API changes fixed just the
scratch of the issues)
3) batch compiler: can use either re.emit or cecli/peapi
4) interactive compiler, interpreters, *->IL JITs: need to use re.emit
5) in the case of compilers that can operate in both batch and
interactive modes: use re.emit, since loading and jitting cecil is just
a waste of resources (and duplicating the emitting code, too)

Hope this helps to understand where Cecil and re.emit fits in.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list