C＃代码生成

我正在为项目创建一个小类生成器。 我一直在阅读有关CodeDOM的内容，因此创建类的语义似乎不是一个问题，但我不确定如何最好地将这一代集成到开发和部署过程中。

1. 我该如何触发类的创建？ 我已经读过它应该是构建过程的一部分，我应该怎么做？

2. 应该在哪里创建课程？ 我读到不应该手动编辑文件，也不要检查源代码控制。 我是否应该担心这一点，只是将类生成到与生成器引擎相同的目录中？

Answer 1

您的问题的答案部分取决于您生成的类的目的。

如果这些类是作为开发的一部分生成的，那么它们应该作为文本文件生成，并像任何其他类一样检入SCM。

如果您的类是在运行时动态生成的，作为系统操作的一部分，我根本不会使用CodeDOM。 我会用reflection。

Answer 2

看看T4模板（它内置于VS2008）。 它允许您创建为您生成代码的“模板”类。 Oleg Sych是一个非常宝贵的资源。

关于Oleg关于代码生成的教程的链接 。

Answer 3

我知道T4模板的存在（并且知道许多人使用它们），但我自己没有使用它们。 除此之外，您有两个主要选择：

1. 使用SingleFileGenerator在项目内部转换源。 每当您保存您编辑的文档时，它将自动重新生成代码文件。 如果使用源代码管理，则生成的文件将作为项目的一部分签入。 这有一些限制：
   • 您只能为每个输入生成一个输出。
   • 由于无法控制生成文件的顺序，并且在构建时不生成文件，因此只能从单个输入文件中有效地导出输出。
   • 如果计划编辑输入文件，则必须在开发人员的计算机上安装单个文件生成器。 由于生成的代码在源代码控制中，如果它们不编辑输入，则它们不需要重新生成输出。
   • 由于输出仅在保存输入时生成，因此输出不应取决于输入文件的确切内容以外的任何状态（即使是系统时钟）。
2. 生成代码作为构建的一部分。 为此，您编写了一个MSBuild目标文件。 为此，您可以完全控制输入和输出，因此可以处理依赖关系。 系统状态可以在必要时被视为输入依赖项，但请记住，每个需要代码生成的构建都需要比使用先前生成的结果的构建更长的时间。 结果（生成的源文件）通常放在obj目录中，并添加到csc （C＃编译器）的输入列表中。 这种方法的局限性：
   • 编写目标文件比单个文件生成器更难。
   • 无论用户是否正在编辑输入，构建都依赖于生成输出。
   • 由于生成的代码不是项目的一部分，因此查看生成的代码（如设置断点）要困难一些。