c# 中的高级元编程是否有一些行业“标准”？

Question

时不时地，在各种项目中，我会在 C# 项目中遇到无法用 generics 解决的元编程情况，并且将受益于更强大的元编程工具。 我通常采用的解决方案是解决反射问题、使用 C++/cli 或引入自定义 xml/xslt 编译器步骤。

这是否反映了 C# 社区总体上采用的方法，还是有一种我不知道的有价值的方法，例如广泛使用的第 3 方预处理器？

我不是在要求产品推荐，我是在询问针对这个常见问题的既定通用解决方案。 “不，没有”可能是有效且正确的答案。

Answer 1

这是一个公认的差距，多年来经常被搁置，因为 .NET 具有非常好的运行时反射/发射 API，允许运行时元编程解决方案； 但是，这有多个问题，包括：

1. 复杂
2. 启动时间
3. 安全隐患
4. 不适用于所有场景（某些运行时/平台禁止运行时发出）
5. IL链接器删除“未使用”的代码的问题（因为在构建时没有任何东西触及这些API，但在运行时它们通过运行时反射/发射使用）

正因为如此，在 C# 9 时间范围内（但不特定于 C# 9），“发电机”看起来终于变成了“东西”。 这提供了一个基于 Roslyn 的构建时元编程层，该层可以以类似于今天第 3 方库如何发布“分析器”的方式进行扩展（生成器和分析器基本相似）。

它可能是您正在寻找的“行业标准”，但它还处于起步阶段。 介绍帖，自 2020 年 4 月起。

Answer 2

不，那里没有。 主要是因为它是一个边缘领域。 不是说它没有用，只是说 90% 到 95% 的人根本不这样做。

有两种“广泛”使用的技术（部分原因是一些 .NET 工具，主要在 EntityFramework 中）确实使用了它们）：

• T4 模板
• PostSharp

我想说，在用例中，95% 是 T4，这基本上是旧的 Ef 4 编辑器，现在正慢慢被各种 API 的客户端生成器所取代——是的，元编程是如此罕见。 我觉得这部分是一种耻辱。 我有时使用过代码生成器（过去，Odata，ASP.NET 的基于 T4 的路由），但在大多数情况下，其他开发人员用大眼睛看待它，甚至从未听说过这个概念。 耻辱。

所以，绝对没有标准。

Answer 3

在 .NET 中有很多方法可以使用元编程。

• 编译时工具：PostSharp、Fody 等
• 运行时工具：Castle DynamicProxy、Unity Interception等
• 代码生成工具：T4、Source Generators

但它们都不是标准的。

还可以考虑切换到不同的编程语言，例如 Nemerle。 它是一种支持卫生宏的语言。 在我个人看来，这是元编程的理想。