时不时地，在各种项目中，我会遇到C#项目中无法用泛型解决的元编程情况，并且会受益于更强大的元编程工具。我通常采用的解决方案是通过反射解决问题，使用 C++/cli，或引入自定义 xml/xslt 编译器步骤。
这是否反映了 C# 社区通常采用的方法，或者是否有我不知道的有价值的方法，例如广泛使用的第 3 方预处理器？
我不是在寻求产品推荐，我是在询问针对此常见问题的既定通用解决方案。 “不，没有”可能是有效且正确的答案。
这是一个公认的差距，多年来一直被搁置，因为 .NET 具有 非常好的运行时反射/发射 API，允许运行时元编程解决方案；然而，这有多个问题，包括：
它可能是您正在寻找的“行业标准”，但它还处于起步阶段。
介绍帖，自 2020 年 4 月起.
有 2 种技术被“广泛”使用（部分原因是一些 .NET 工具，主要是在 EntityFramework 中）确实使用了它们：
我会说在用例中，95% 是 T4，这基本上是旧的 Ef 4 编辑器，现在慢慢被各种 API 的客户端生成器所取代——是的，元编程很少见。我觉得这部分是一种耻辱。我有时会使用代码生成器（odata，过去用于 ASP.NET 的基于 T4 的路由），但在大多数情况下，其他开发人员会睁大眼睛看着它，甚至从未听说过这个概念。耻辱。
所以，绝对没有标准。
还可以考虑切换到不同的编程语言，例如 Nemerle。它是一种支持卫生宏的语言。在我个人看来，这就是元编程的理想。
Metalama。它是 最近发布的，我非常喜欢并推荐这个工具。它是 PostSharp（众所周知的方面框架）的现代重写，但它基于 Roslyn API 并与现代 .NET 一起工作，并且它有一些 PostSharp 中没有的新的和非常好的功能:)
它允许您非常轻松地创建方面，还可以进行各种分析、代码修复、在有人违反您的代码库规则时创建警告等等……而且它很好地集成到 Visual Studio 和 VS Code 中，所以您可以使用“Metalama Diff”在设计时查看转换后的代码，还可以轻松调试转换后的代码。您可以将 Metalama 与 Roslyn API 结合使用，这要归功于 Aspect Weavers，它甚至允许您对 C# 代码进行任意转换 :) 这完全让我着迷，因为 Roslyn API 本身甚至不可能做到这一点 :D
而且这个 Metalama 工具是全新的，适用于现代 .NET 并在设计时运行，因此与 Castle DynamicProxy 等古老的运行时库相比，它具有许多优势。 与 T4 模板等模板语言相比，Metalama 使用 T# 模板语言感觉更现代。
如果您对现代元编程方式感兴趣，可以加入 Reddit 上的这两个社区 :)