C# Code Generation

Question

I am looking at creating a small class generator for a project. I have been reading about CodeDOM so it the semantics of creating the classes does not appear to be an issue, but am unsure oh how to best integrate the generation into the development and deployment process.

1. How should I trigger the creation of the classes? I have read it should be part of the build process, how should I do this?

2. Where should the classes be created? I read that the files should not be edited by hand, and never checked into source control. Should I even worry about this and just generate the classes into the same directory as the generator engine?

Answer 1

Take a look at T4 templates (it's built in to VS2008). It allows you to create "template" classes that generate code for you. Oleg Sych is an invaluable resource for this.

Link for Oleg's tutorial on code generation.

Answer 2

The answers to your question depend partly on the purpose of your generated classes.

If the classes are generated as a part of the development, they should be generated as text files and checked into your SCM like any other class.

If your classes are generated dynamically at runtime as a part of the operation of your system, I wouldn't use the CodeDOM at all. I'd use Relfection.

Answer 3

I know of the presence of T4 templates (and know many people use them), but I have not used them myself. Aside from those, you have two main options:

1. Use a SingleFileGenerator to transform the source right inside the project. Whenever you save the document that you edit, it will automatically regenerate the code file. If you use source control, the generated file will be checked in as part of the project. There are a few limitations with this:
   • You can only generate one output for each input.
   • Since you can't control the order in which files are generated, and the files are not generated at build time, your output can only effectively be derived from a single input file.
   • The single file generator must be installed on the developer's machine if they plan to edit the input file. Since the generated code is in source control, if they don't edit the input then they won't need to regenerate the output.
   • Since the output is generated only when the input is saved, the output shouldn't depend on any state other than the exact contents of the input file (even the system clock).
2. Generate code as part of the build. For this, you write an MSBuild targets file. For this, you have full control of input(s) and output(s) so dependencies can be handled. System state can be treated as an input dependency when necessary, but be remember that every build that requires code generation takes longer than a build which uses a previouly generated result. The results (generated source files) are generally placed in the obj directory and added to the list of inputs going to csc (the C# compiler). Limitations of this method:
   • It's more difficult to write a targets file than a SingleFileGenerator.
   • The build depends on generating the output, regardless of whether the user will be editing the input.
   • Since the generated code is not part of the project, it's a little more difficult to view the generated code for things like setting breakpoints.