why does reflection.emit work with dynamic assemblies only.

Question

it is possible to load an executable and fiddle with the pe format and alter the il of functions. but it is not possible to rewrite the il of a function in the currently executing assembly using reflection emit services. why is that feature not supported.

thanks in advance

Answer 1

My guess is that there is/was not major customer scenario for such feature. Do you have one? Can you describe it? Maybe there is alternate solution which we can help you with (e.g. using delegates).

Implementing something like this would be quite difficult in current CLR design and the benefit is questionable. One scenario where something similar is needed are profilers - they need to instrument IL. There are special profiler APIs to support that scenario, but emitting of the IL has to happen via native API, not via Reflection.

-Karel

Answer 2

One benefit would be to offer better support for AOP and runtime interception in general. You can off course do it with proxies but that has its limitations - like intercepted methods have to be virtual. You can also do it with a post compiler or by using the profiling API w. IL rewriting but those have limitations as well : you cannot instrument signed assemblies for which you don't have the key, profiliing API disables strong name verification and it has performance implications which make its use questionable for production systems.  

Answer 3

Hi, everyone.  As p.b.a. mentioned, a post-compiler step is an option, and some profiler tools do that.  And yes, it will blow away any strong name verification unless you can resign it afterward.

Using the profiling API at run-time is another option.  Note that this dose not turn off strong name verification--however, the strong name / signature verification happens when the assembly is loaded (or, I believe when it was added to the GAC if it's in the GAC).  The profiler then has the power after that verification is complete to modify the IL in-memory without fear of encountering strong name signing issues.  In fact, there are several production monitoring tools that use the profiling API to rewrite IL in memory.  You can find a quickie overview of the procedure here: http://blogs.msdn.com/davbr/archive/2007/03/06/creating-an-il-rewriting-profiler.aspx

The limitations with the profiling API are around the kinds of metadata changes you can make, and around the "window of opportunity"--you have one opportunity to modify metadata and IL, which is before they get used.  Once classes are loaded / IL is JITted, your opportunity is over.  Since it is a common request to be able to modify metadata & IL later on, we are looking into what it would take to offer that as a feature in a future release of the CLR.  Another limitation, as mentioned above, is that the profiling API can only be used by native code.  You cannot use managed code to do your instrumentation.

It does sound nice for us to allow the Reflection.Emit methods to work against arbitrary assemblies.  But as Karel said, this would be a huge undertaking for the CLR team, and with the alternatives mentioned above, it's not very high on our priority list.  Still, we'd be interested in hearing more about your scenario that cannot be done with currently available techniques.


Thanks,
Dave

Answer 4

Dave,

I was referring to code access permissions - are those enabled as well when profiling is on ?

Paul

Answer 5

Hi, Paul.

Yes, code access security is enforced while profiling is on.


Dave

Answer 6

Thanks for clarifying that, I was under the wrong impression that having a profiler active disables some security checks.

Paul