C # code generation

Question

I am looking for a generator of small classes for a project. I read about CodeDOM, so the semantics of creating classes is not a problem, but I'm not sure how best to integrate the generation into the development and deployment process.

• How can I initiate the creation of classes? I read that this should be part of the build process, how do I do this?

• Where should classes be created? I read that files should not be edited manually and never checked in the original control. Do I even have to worry about this and just generate classes in the same directory as the generator engine?

Answer 1

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

If classes are generated as part of development, they should be generated as text files and tagged in your SCM, like any other class.

If your classes are dynamically generated at runtime as part of your system work, I would not use CodeDOM at all. I would use Reflection.

Answer 2

Take a look at the T4 templates (it is built into VS2008). This allows you to create “template” classes that generate code for you. Oleg Sych is an invaluable resource for this.

Link to Oleg’s code generation tutorial .

Answer 3

I know about the availability of T4 templates (and I know that many use them), but I have not used them myself. In addition, you have two main options:

• Use SingleFileGenerator to convert the source directly to the project. Whenever you save a document that you are editing, it automatically restores the code file. If you use the original control, the generated file will be checked as part of the project. There are several limitations:
  • You can only generate one output per input.
  • Since you cannot control the order in which the files are created and the files are not generated during assembly, your output can be effectively obtained from only one input file.
  • A 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 do not edit the input, then they will not need to regenerate the output.
  • Since the output is generated only when the input is saved, the output should not depend on any state other than the exact contents of the input file (even the system clock).
• Generate code as part of the assembly. To do this, you write the MSBuild goals file. To do this, you have full control over the input (s) and output (s) so that you can handle the dependencies. The state of the system can be considered as an input, when necessary, but remember that each assembly that requires code generation takes longer than the assembly that uses the previously generated result. Results (generated source files) are usually placed in the obj directory and added to the list of inputs going to csc (C # compiler). Limitations of this method:
  • It’s harder to write a goal file than SingleFileGenerator.
  • The line depends on the generation of the output, regardless of whether the user edits the input.
  • Since the generated code is not part of the project, it’s a little harder to look at the generated code for things like setting breakpoints.