The first option refers to the System.CodeDOM and System.CodeDOM.Compiler namespaces, and it's been present in .NET since the very first version of the framework. Note the DOM part of the name: it means Document Object Model, just like in HTML, XML, or other document structures.

With classes inside CodeDOM, we can generate source code using templates that define coding structures in different languages, so we can even generate source code in all languages supported by .NET Framework.

To generate code for any .NET structure, CodeDOM classes represent any aspect of the generated code, and we should use two different mechanisms: one that expresses the elements to be built and another that—when lunched—produces the actual code.

Let's imagine how can we generate the previous Person class; only, reduce it to a minimum of elements for sake of clarity.

We will need the following:

Let's take a look at the code, which produces a file that contains the same definition of a Person class that we used at the beginning of this chapter (for the sake of brevity, I'm just including here the initial lines and final lines. You'll find the whole code in demo Reflection1 inside this chapter's source code):

using System.CodeDom;
using System.Reflection;
using System.CodeDom.Compiler;
using System.IO;

namespace Reflection1
{
  class Program5
  {
    static void Main(string[] args)
    {
      CodeCompileUnit oCU = new CodeCompileUnit();
      CodeTypeDeclaration oTD;

      // Working with CodeDOM
      CodeNamespace oNamespace = new CodeNamespace("Reflection1");
      // CodeNameSpace can import declarations of other namespaces
      // which is equivalent to the "using" statement
      oNamespace.Imports.Add(new CodeNamespaceImport("System.Windows.Forms"));
      // Class creation is undertaken by CodeTypeDeclaration class.
      // You can configure it with attributes, properties, etc.
      oTD = new CodeTypeDeclaration();
      oTD.Name = "Person";
      oTD.IsClass = true;


      // Generate code
      CodeDomProvider provider = CodeDomProvider.CreateProvider("CSharp");
      CodeGeneratorOptions options = new CodeGeneratorOptions();
      options.BracingStyle = "C";
      using (StreamWriter sr = new StreamWriter(@"Person.cs"))
      {
        provider.GenerateCodeFromCompileUnit(oCU, sr, options);
      }
    }
  }
}

Once we establish our entry point in Program5, its execution generates a file with the same code that we had in the Program.cs file.

You should see something like the following screenshot in your Solution Explorer:

As you can see, the generated code is pretty verbose. However, that's what it takes to generate code feature by feature. Let's go briefly through it and underline the most important classes implied in the generation, starting with the end of the Main method.

The object that puts everything to work is the CodeDomProvider class. It has to be instantiated, indicating the language to be used (CSharp, in our case). At the end, we will invoke its GenerateCodeFromCompileUnit method, which will use all previous definitions to produce the actual code inside the file defined for this purpose.

So, at the top of Program5, we declare a CompilerUnit object. The other crucial component is the CodeTypeDeclaration object, which is in charge of storing all declarations used while code generation takes place.

The rest of the classes implied in the construction are merely helper classes to build each brick of the resulting class. This is the role of the CodeNamespace, CodeNamespaceImport, CodeSnippetTypeMember, CodeCommentStatement, CodeMemberMethod, and CodeParameterDeclarationExpression classes.

Although you may think that this is too much effort to just create the resulting class, keep in mind that the automatization of tasks inside Visual Studio follows similar paths and that you could create you own mechanisms of code generation suited to your needs or the company's requirements.

With such programmable context, it's easy to imagine a number of situations in which code generation can be tuned by the generating program at runtime, allowing you to produce code with different variations depending on options we established previously.

The System.Reflection.Emit namespace is intended for code generation, allowing developers to create code or metadata from within their applications, independent of the specifics of the operating system's loaders.

Basically, this namespace offers the following programmatic options:

The way the code is generated here is different from CodeDOM in several aspects. One of them is the ability to generate IL code at runtime, which means that the execution of some C# code will produce outputs not coded in C# but using these instruments.

One of the objects implied in this type of code generation is the DynamicMethod object included in the System.Reflection.Emit namespace. This object allows the obtention of another object of type ILGenerator.

Once you get ILGenerator, you can produce IL code dynamically in a very straightforward manner:

// 1st sample of emission (using ILGenerator):
// A way to obtain one is creating a dynamic method. When the
// method is invoked, its generated contents are executed.
DynamicMethod dn = new DynamicMethod("dynamicMethod", null, null);
var ilgen = dn.GetILGenerator();
ilgen.EmitWriteLine("Testing Reflection Emit.");
ilgen.EmitWriteLine("We use IlGenerator here...");
ilgen.Emit(OpCodes.Ret);
dn.Invoke(null, null);

Observe how we finally call the DynamicObject.Invoke method as if it were a delegate. If you test the previous code, the output generated will correspond to what is the equivalent of the counterpart lines of the code programmed in C#, which produces the same information in the output:

Also, note the presence of the OpCodes.Ret value in the last call to ilgen.Emit. This generates a return statement, which pushes the return value, if present, from the evaluation stack to the caller's evaluation stack.

If you take a look at fields related to OpCodes, you'll discover that it provides an extensive list of field representations of MSIL instructions, as shown in the next screenshot: