Architecture

The classes that implement dynamic code generation are based on two different methodologies, depending on whether you are generating source code or IL code, as shown in this diagram:

The diagram indicates which namespaces contain classes that can make the conversions shown in the arrows. What the diagram shows is that the Reflection.Emit classes can be used to directly create an assembly and add IL code to that assembly. The Reflection.Emit classes are based on a very similar object model to the System.Reflection classes.

On the other hand, the System.CodeDom classes can create a DOM - a document object model. This DOM is also sometimes referred to as a CodeDom and indicates the structure of program in a source-language-neutral way. In other words, it might indicate that the code should define a namespace X, which contains class Y. Class Y contains method Z, which contains statements to perform certain operations. However, this is all stored in a way that is independent of the syntax of any given language (the DOM exists as a tree-structure of object references in the System.CodeDom namespace, as we'll see shortly).

The use of the term DOM (document object model) to describe the document hierarchy that represents a particular piece of source code can sound confusing since it is a highly non-intuitive terminology. Unfortunately, it's the terminology Microsoft has given us, so we'll have to live with it in this chapter.

The diagram indicates "CodeDom.Compiler and related" as the namespaces that contain classes that can operate on the DOM. These classes can convert the DOM into source code, the source code into an assembly, or the DOM directly into an assembly. What do I mean by "and related?" The CodeDom.Compiler namespace contains interfaces, abstract base classes, and some supporting helper classes to assist in performing these operations, but without reference to any particular language. For example, it contains an interface, ICodeGenerator, which defines the methods required to convert a document tree into source code. If you want to actually generate, say, C# source code, then you need a class that actually implements this interface to generate C# code. If you want to generate VB source code then you need another class that implements the same interface. And so on for the other languages. Microsoft has supplied classes that provide these implementations for several languages, most notably in the Microsoft.CSharp and Microsoft.VisualBasic namespaces. Of course, other companies can choose to supply implementations for other languages. At the time of writing, there is no Microsoft-supplied implementation for managed C++ - so you can't dynamically generate C++ source code files.

You'll have gathered from this discussion that dynamic code generation is really founded on two fundamentally different technologies. The underlying object models for the Reflection.Emit classes and the CodeDom classes are essentially independent, and the classes are used in very different ways. Accordingly, we will treat the two areas separately in this chapter. We'll examine the Reflection.Emit classes first, then look at the CodeDom and related classes in the second part of the chapter.

Before we look at the actual coding using Reflection.Emit and CodeDom, I should point out one other alternative: you can write code that directly outputs the text representing the source code to a file, and then, if required, compiles this code. Obviously if you do that you won't get the language-independence: you'll have to write completely separate code if you want to swap output languages, but this may still be an appropriate technique depending on your project's requirements. When I present the CodeDom examples, we'll see that CodeDom does lead to quite long and complex code, so you may decide that ignoring CodeDom and directly figuring out the source code text in your code is a better option. In a similar manner, you could write code that outputs the binary content of assemblies directly, without using the Reflection.Emit classes - however, for generating IL, there's unlikely to be much benefit in doing that since the Reflection.Emit classes do a lot of work for you in terms of automatically generating the PE and CLR headers and metadata - which would be a very major task to do by hand.