CodeDom 有官方替代品吗？答案

【问题标题】：Is There an Official Replacement for CodeDom?CodeDom 有官方替代品吗？
【发布时间】：2013-01-25 15:53:20
【问题描述】：

我正在研究 System.CodeDom namespace 以生成与语言无关（至少在一定范围内）的源代码，并且我发现了一些不鼓励使用 CodeDom 的信息。

我认为this early blogpost 中描述的一些遗漏现在已经修复，CodeDom does not seem to provide a way to create a switch statement 仍然允许 - 性能降低？ - 解决方法，而不用丑化生成类型的公共接口。这同样适用于automatic C# properties 和collection initializers。

但是，其他遗漏无法真正解决，例如inability to create finalizers、impossibility to declare extension methods 或lacking direct support of generic reference type constraints。

请注意，使用 CodeSnippetTypeMember 或通过任何其他方式注入文字源代码 sn-ps 的建议解决方案并不令人满意，因为它们与语言无关 - 从而消除了使用 CodeDom 而不是 String.Format 的全部意义使用文字代码 sn-ps。

最后，甚至有人建议 in this SO question 'CodeDom 是失败的，而表达式树（或者更确切地说是“语句”树）是前进的方向' - 尽管没有任何解释如何从 @ 实际获取任何源代码987654331@（除了classes cannot be declared with expression trees的限制。

CodeDom 是否仍然是生成源代码的首选方法，或者当前的 BCL 是否提供了任何我没想到的名称的晦涩替换？

【问题讨论】：

stackoverflow.com/questions/7852926/microsoft-roslyn-vs-codedom
@DavidBrabant（以及driis，之前曾指出过这一点）：谢谢，Roslyn 只是您无法找到的软件名称之一，除非您已经认识他们。在选择将其称为已接受的答案之前，我将花一些时间对此进行研究。
@O.R.Mapper 我认为这同样适用于 .Net 中大多数技术的名称：LINQ、Entity Framework 或 CodeDOM。
此外，您的要求有点矛盾：您想要的东西与语言无关，但同时支持所有特定于语言的功能。
@svick：的确，许多软件名称都受此影响，尽管您命名的名称仍然不言自明（在 LINQ 的情况下，至少如果您发现首字母缩写词代表什么)。尽管如此，我认为我的要求没有任何矛盾：IL 代码也不矛盾，只是因为它可以从具有特殊功能的各种语言编译成。而一些“特殊功能”只是在某些语言中编写某些代码元素的唯一方式，例如 C# 中扩展方法的 this 关键字。

标签： .net code-generation codedom

【解决方案1】：

我认为 CodeDom 在今天仍然是 BCL 中的最佳解决方案，但是：Roslyn 项目已经进行了很长时间，并且已经推出了几个 CTP。目标是将编译器作为服务提供，它将通过简单的 API 实现代码生成和代码检查场景。

看看它，如果您可以为您的项目使用预发布位：Roslyn CTP。这是一个相关的（虽然已经过时，但仍然有一些很好的信息）StackOverflow 问题：Microsoft Roslyn vs. CodeDom。最后，还有一篇关于使用 Roslyn 进行代码生成的文章：Code Generation in .NET with the Roslyn CTP

【讨论】：

我不会简单地调用 API，尤其是与 CodeDOM 相比时。例如，要创建一个简单的自动属性，您需要this monstrosity。

【解决方案2】：

没有。 CodeDom 可用于生成代码以执行。它生成文本的能力只是一个偶然的副产品，因为编译器需要文本而需要它。如果你真的关心文本，那么有很多理由不喜欢 CodeDom，而且框架中没有任何东西可以帮助你。

其他解决方案同样侧重于生成可执行代码。 Reflection.Emit 生成 IL，.NET 中的通用语言，但没有提供简单的反编译方法，尽管任何体面的反编译器（ILSpy、Reflector 等）肯定会有所帮助。 Linq.Expressions 是纯可执行代码，通常对生成完整程序没有用处。 Roslyn 非常倾向于已经拥有文本。

可能最好的方法是弃用您对使用特定语言的文本的要求。所有 .NET 编译器都具有相同类型的输出，它们都编译为 IL。这使得将您的选择限制为一种语言成为一种可行的方法。从您的问题中不清楚这是否是一个合理的限制。这似乎是一个常见的选择，我想不出一个曾经试图解决 CodeDom 限制的项目。 codeplex.com 上提供的以 CodeDom 为目标的项目类型试图尽量减少使用 CodeDom 的代码所需的冗长带来的痛苦。

【讨论】：

我正在创建一个可以使用 Xml 文件配置的库，并且通过运行时检查可以通过库的类型访问 Xml 文件中定义的所有内容，作为我提供的一项额外服务一种基于 Xml 配置文件自动为包装类创建代码的工具。这将增加编译时检查对 Xml 文件中定义的内容的访问的好处。
这个生成器适用于 C#，但也支持其他语言会很好，因此用其他 .NET 语言创建的项目可以像 C# 项目一样轻松地包含其包装类源文件。与其基本上从头开始为每种语言编写生成器（主要由源代码片段组成），不如将包装类定义为抽象代码模型一次，然后将其提供给所需语言的源代码生成器，这看起来像对我来说是一个更清洁的解决方案。
好吧，给你。让这些其他语言项目添加对 CodeDom 生成的程序集的引用要简单得多。程序集中的元数据与语言无关，任何 .NET 语言都可以使用它。
这听起来像是一个可行的解决方案，但我对增加要引用的程序集的数量持谨慎态度（尤其是当附加程序集仅包含少数附加类时），因为经常有许多程序集似乎被视为反模式（例如here、here 或here）。