Back to VSLive! San Francisco Show Daily Home

	email article
	printer friendly

CodeDom-Reflection.Emit Comparison
When is CodeDom the better choice?
by Josh Holmes

VSLive! San Francisco, March 25, 2004

Note: Josh Holmes is presenting "Using CodeDom to Wrap, Extend, Generate, Assemble, and Load New Code On the Fly" at VSLive! San Francisco on Friday, March 26. This tip is from that session.

You can choose between two ways to generate an assembly from your .NET applications dynamically: CodeDom and Reflection.Emit. In this article, I'll explain the differences between CodeDom and Reflection.Emit and give you guidance to decide which one is best under which circumstances so you can use the most appropriate tool for your situation.

The biggest difference between CodeDom and Reflection.Emit is that CodeDom produces C#, VB.NET, Visual J#, and other .NET languages, while Reflection.Emit produces raw Intermediate Language (IL) statements. CodeDom doesn't require in-depth knowledge of IL, so it can be far easier to use. The downside is that you're restricted to the set of actions and types all the languages can access, which eliminates the use of overloaded operators or other language-specific idioms. The upside is that you can switch easily between the output languages by simply using a different code provider. CodeDom can also incorporate C# or VB.NET code if it matches the output language.

Reflection.Emit is extremely powerful and can do many things CodeDom cannot because it allows you to write any legal IL statement. Its biggest hurdle is that it requires you to understand and write MSIL. Reflection.Emit gives you the capability to push and pop items right on the stack with the actual MSIL instructions. This is sometimes beneficial, but it can also be a drawback as it removes the productivity offered by the higher-level languages.

This code example builds a main with a return using the CodeDom, which produces a high-level .NET language:

CodeEntryPointMethod main = 
   new CodeEntryPointMethod();
main.Statements.Add(new System.CodeDom.
   CodeMethodReturnStatement());

Here's the same main build with Reflection.Emit, which produces raw IL:

MethodBuilder methodbuilder = 
   typeBuilder.DefineMethod("Main", 
   MethodAttributes.HideBySig | MethodAttributes.Static | 
   MethodAttributes.Public, 
   typeof(void), new Type[] { typeof(string[]) });

ILGenerator ilGenerator = methodbuilder.GetILGenerator();
ilGenerator.Emit(OpCodes.Ret);
assemblyBuilder.SetEntryPoint(methodbuilder, 
   PEFileKinds.ConsoleApplication);

There are some significant differences: The CodeDom has a class that creates an entry point, whereas the Reflection.Emit code must manually build the method and set the entry point. Look at the return: Again, the CodeDom has a class that does the work, while the Reflection.Emit code must output the IL instruction for a return.

Whether you use CodeDom or Reflection.Emit depends on your situation.

Use CodeDom when you:

• Write a code generation tool.
• In any situation where you want the result to be C#, VB.NET, or any other high-level language.
• Use C# or VB.NET code snippets.

Use Reflection.Emit if you:

• Require tight control over the IL optimizations.
• Do non-Common Language Specification (CLS)-compliant actions such as unsafe code.

You can use either of the generation techniques if your assembly generation work does not fall into one of the previous categories and you only need dynamically generated assemblies. In most situations, the CodeDom will be preferable because it's easier to use and allows generation of many different languages.

Both are strong tools used in different circumstances. Follow the basic guidelines: Use CodeDom if you're writing tools or need higher-level code generation. Use Reflection.Emit for lower-level control over your generated assemblies.

About the Author
Josh Holmes has been a software developer and trainer for eight years, and provides training and mentoring services to software developers in the areas of XML, C++, VB, enterprise application design, and Windows DNA. He recently wrote an XML/COM-based client architecture for a user-driven, configurable user interface, and an XML-based reporting system that delivered reports to hybrid clients.