[Mono-dev] Edit and Continue / Function body rewrite

Kornél Pál kornelpal at gmail.com
Fri Jul 7 15:05:33 EDT 2006

You cannot use Mono's System.Reflection.Emit on Microsoft .NET Framework 
runtime because both implementation rely on internal calls that requires the 
same runtime and mscorlib.dll version.


----- Original Message ----- 
From: "David Srbecky" <dsrbecky at gmail.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Friday, July 07, 2006 9:00 PM
Subject: Re: [Mono-dev] Edit and Continue / Function body rewrite

> Brian Crowell wrote:
>> David Srbecky wrote:
>>> The idea is that I will emit disk assembly using
>>> System.Reflection.Emit as usually, but later on I will re-emit body of
>>> some function and fetch changed data into memory. Once I got the data
>>> I can feed it to the .NET runtime - that should not be a problem.
>> Er, I don't know the full internals of the Mono runtime, but I suspect
>> this is not that easy to do. Correct me if I'm wrong, but I think one of
>> the main reasons assemblies cannot be unloaded is that it allows you to
>> make some very nice assumptions about the immutability of code-- for
>> example, that function pointers will not change. It may require patching
>> previously JITted code to reference a new function.
>> Of course, I'd be happy to be wrong about this. Obviously, since
>> Microsoft did it, there must be a way.
>> --Brian
> Yes, you are right - changing running program is probably extremely
> difficult, but I want to use Microsoft runtime which has this
> functionality already implemented and available via really simple API.
> So this is not a problem.
> The problem is that I need to get the new IL code and metadata for the
> new function from System.Reflection.Emit.
> My question is how difficult is it to patch System.Reflection.Emit to
> support this.
> David
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list 

More information about the Mono-devel-list mailing list