Reasons to Use Dynamic Code Generation

Traditionally, code generation has been associated with compilers. However, the .NET Framework libraries make code generation sufficiently easy that it becomes feasible and potentially useful in a number of different scenarios, which I'll quickly review here:

Developer Tools

You'll be used to developer tools which can auto-generate code for you, the most obvious example being Visual Studio .NET's Design view and Properties window. Other examples from Microsoft include the xsd.exe tool which can generate a source code file from an XML schema, and the wsdl.exe tool, which can generate client source code for XML services. Other situations in which dynamic code generation is important include:

• Templates - version 1 of the .NET Framework has often been criticized for not including much support for generics (which offer similar, though more restrictive, features to unmanaged C++ template classes). Since in practice a template is not really more than a definition that allows the compiler to generate and compile multiple classes (or methods) from the same definition, it should be obvious that a developer tool could use dynamic code generation to implement the same kind of feature.

• UML-based coding - dynamic code generation can be used to implement tools in which developers use some kind of diagram to indicate the code they wish to write - and the tool generates the code for them. An obvious example of this is generation of code from UML diagrams.

• Language conversion - the multi-language support in the .NET Framework should theoretically reduce the need for source code to be converted between languages, because the source language that an assembly was originally compiled from is to a large extent irrelevant to clients of that assembly. Nevertheless, there is occasional demand amongst developers or organizations for applications that can convert source code between languages. Dynamic code generation can assist in the implementation of this kind of application.

• Modifying Assemblies - there are some situations in which you might need to take the instruction stream in an assembly and modify it prior to executing it - for example to provide notifications of when certain IL instructions are executed. Obfuscators also need to permanently modify the contents of assemblies, and in a similar vein you might want to write some software that optimizes the IL code in other assemblies (since compilers such as the C# and VB.NET ones perform very little optimisation of the emitted IL code).

For Performance Reasons

There are certain types of application for which dynamic code generation is likely to be the technique that will give the highest performance. The typical scenario is when the purpose of some method in a library is so general that the actual algorithm that should be used to accomplish the task is not necessarily known at compile time. A couple of examples that illustrate the kind of situation we are talking about are as follows:

• Eval(). The Eval() function as used in such languages as pre-.NET VBA and VBScript allows evaluation of an arithmetic expression that is supplied as a string. For example, you can write Eval("10+5"), which would return 15. More complex examples might involve variables or names of functions to be invoked in the Eval expression.

  The expression supplied determines the basic algorithm that Eval() needs to implement. If the expression is to be executed a number of times then it doesn't really make sense to parse the string every time in order to determine what the program is required to do - since parsing the string is going to be significantly more processor-intensive than actually doing the calculation. In this case, a more sensible option is to parse the string once and use the results to dynamically generate code that evaluates the expression.

• Regular expressions. Regular expressions form another situation in which the actual programming needed to evaluate a particular regular expression is very dependent on the expression supplied. If you supply a regular expression to some code (such as the relevant classes in the System.Text.RegularExpressions namespace), then a large part of the processing involves parsing the regular expression string and figuring out exactly what you want done. Thus any code that is capable of evaluating any regular expression supplied to it is clearly going to have significantly worse performance than some code that is specifically geared to executing a particular regular expression. So once again on performance grounds, if a particular regular expression is to be executed a number of times, a program will perform better if it dynamically compiles the code needed to evaluate each regular expression the first time it encounters that expression. It turns out that dynamic code generation using System.Reflection.Emit classes does feature in the internal implementation of some of Microsoft's regular expression classes.

• Reflection. One of the main benefits of .NET custom attributes is the fact that other code can later read any attributes you define, and modify its own execution path based on the attributes. Dynamic code generation based on the values of attributes may play a role here. One example of this would be where classes are to be instantiated based on the System.Reflection classes. It is possible to instantiate and use classes using methods such as Activator.CreateInstance() and MethodInfo.Invoke(), but these methods need to use reflection internally to perform their tasks, and are therefore much less efficient than invoking the constructor and required methods directly. Once again, dynamic code generation could be used as an alternative technique - and can give performance benefits if the methods are to be invoked many times.

• Data Access. A program could analyse the structure of the database, and then, based on the database structure, dynamically generate IL, C#, or VB code to access the database efficiently.