Real world uses of Reflection.Emit

Question

In all the books I've read on reflection they often say that there aren't many cases where you want to generate IL on the fly, but they don't give any examples of where it does make sense.

After seeing Reflection.Emit as a job requirement for a gaming company I was curious where else it's being used.

I'm now wondering if there are any situations you've seen in the real world were it was the best solution to the problem. Perhaps it is used as an implementation to a design pattern?

Note I imagine PostSharp / AOP uses it.

Answer 1

I'm using it as a way to create dynamic proxies on the fly to wrap a class. NHibernate uses this same pattern to proxy calls to POCO objects to instead query a database.

Any time you want to be able to "write code" (i.e. create a new function, etc.) dynamically, you'll need Emit.

Answer 2

Duck Typing

Answer 3

The XMLSerializer actually generates code and compiles it on first run. You can read this great blog post on Scott Hanselman's site regarding how to debug XML Serialization if you know this is happening.

Answer 4

The DLR and DLR related languages heavily rely on Reflection.Emit

Answer 5

Castle DynamicProxy uses it for, you guess, dynamic proxies. DynamicProxy is then used by the Castle's IoC container Windsor and OR mapper ActiveRecord.

Answer 6

Mocking libraries also use Reflection.Emit to generate proxies used in Unit Testing.

Answer 7

Dynamically generating a mock object which implements some interface. Example frameworks which do this: moq, rhino mocks.

Answer 8

I remember seeing Relection.Emit used in chapter 8: "On-the-Fly Code Generation for Image Processing" of Beautiful Code. Basicly the author specializes a function for doing a certain set of image processing operations on a given image, which in turn leads to greatly reduced execution time.

Answer 9

Expression.Compile essentially does this - that is key to some of LINQ.

I am currently using reflection emit to re-write a serialization API - because sometimes reflection just isn't good enough. As it happens this will also allow it to generate dlls (much like how sgen works), allowing fully static code (I'm hopeful this will make it iPhone friendly).

I also use a similar approach in HyperDescriptor to provide very fast name-based property-lookup.

I've also used emit to do things like:

• AOP (cache injection)
• interface list wrapping
• compare objects

all related to SO questions.

Finally, this IL approach is the core of protobuf-net "v2"; the reason here is that it allows me both to have a fast model at runtime (compiling it via IL on the fly), and to write the same directly to a static-compiled dll, so that it works on things like iPhone, Phone 7, etc (which lack the necessary meta-programming APIs).

Answer 10

I have recently used it to create a proof of concept for compiling a set of operations that's very expensive to do at runtime, and achieved a 200% improvement in speed. The operations were to use RegEx to parse a large string, and loop over the matches, use Reflection to find and instantiate types, and a bunch of other things that aren't exactly fast. By using IL emit, I created dynamic functions that matched a delegate type (using DynamicMethod) and cached them. I did the normal RegEx/Reflection dance once per input value to figure out what it should do, then used StringBuilder to concatenate the strings as literals, and instead of Reflection/Activator I now could use the actual types themselves in the emitted IL. Here's a helpful tip: don't try to write IL yourself unless you're a sado-masochist. Write a sample function or type in C# that does what you want, compile it, and use Reflector or ILDASM to see the generated IL. Then use Emit to do similar logic. Another tip is you can create locals and store them to variables, then use Emit(OpCodes.Ldloc, myLocalVar) and it'll get the local address for you, instead of having to keep track of the local index (i.e. ldloc_1).

Answer 11

I've used it in an application where a property had to be accessed repeatedly via reflection (because the property name was not known at compile time).

By creating a helper class at runtime that generates code to access the property, the resulting code was an order of magnitude faster than the original reflection-only code.