Mono Cecil与PostSharp Core对比Microsoft CCI实施AOP框架

Question

在功能，易用性，文档，示例，社区/支持，VS集成，已知实现，长期可行性以及实现自定义AOP框架的构建速度方面哪个更好？

我将从我所知道的开始（到目前为止我只尝试过PostSharp）：

• Microsoft Common Compiler Instrastruture（CCI）：我读过这个 用于FxCop，ILMerge，Spec＃和 代码合同。它似乎是非常低级as it does not even take care of correcting offsets for branch codes that are borken when IL is modified with it。
• PostSharp 是5岁，有很多 AOP的能力（例如摘要 你需要做的一些事情 使用IL手动完成），来源 代码可用，开发/支持 只有一个人，但他正在计划 使这成为一项业务，已经 文档，但可能会更好， 构建需要大约两倍的时间 关于如何注射IL的小样本 版本2.0即将发布 这有望得到很大改善。
• Mono Cecil ：由一个人写的，部分 单声道套房，有一个 Reflector的插件名为Reflexil 使用Mono Cecil。

Answer 1

Microsoft.CCI和Mono.Cecil都是低级别的，并且不验证生成的程序集。如果生成的代码或汇编结构中存在任何错误，则需要花费大量时间才能找到问题的原因 我建议使用PostSharp，如果它的功能足以满足您的任务 否则...... Mono.Cecil具有更好，更易理解和易于使用的对象模型。但是，当我在我的程序中使用它时，我有一个丑陋的错误（在程序集中保存了对错误方法的引用;我认为元数据令牌处理存在一些错误）
Microsoft.CCI拥有一个丑陋，完全过度设计的对象模型，同时缺少许多简单的功能;然而，它比Mono.Cecil更成熟。最后，我放弃了Mono.Cecil，并将Microsoft.CCI用于我的程序。

Answer 2

与大多数已经存在的框架一样，我建议您实施自己的AOP框架：不要这样做。已经有几个已经存在，包括（即将成为）商业支持的PostSharp，以及CThru，一个由Typemock支持的AOP框架。

但无论如何，我发现Mono.Cecil非常容易使用。它很好地抽象了处理Reflection.Emit的需要，它得到了Mono社区的支持。

我建议你看一下LinFu - 它是一个开源的库集，其中一个是在Mono.Cecil之上实现的AOP框架。关于CodeProject的LinFu AOP上有一篇很好的文章。

Answer 3

AFAIK，LinFu建立在Mono.Cecil上。

我想说PostSharp.Core具有比其他框架更多的高级功能，因此用于较大的作品的难度较小。您也可以在低级别工作，但不能在二进制级别工作（按设计）。您可以使用PostSharp执行程序集合并/收缩程序，但它使用ILASM进行编译的事实会设置一些限制（例如，即使内部成员也应该命名）。另一方面，使用ILASM作为后端使得在PostSharp的顶部开发变得更加容易，因为ILASM验证了许多规则，您可以轻松读取生成的MSIL代码。 PostSharp甚至允许您将注释放入MSIL以帮助调试代码生成。

另一点：如果你想做一个自定义方面（例如，你开发一个数据库引擎并希望提供持久性方面），你需要的不仅仅是一个MSIL重写器。您需要一个能够为您完成大部分工作的AO基础架构。当您开发自定义方面时，我会说1％的工作是针对您的自定义方面的，39％是方面基础架构，60％是MSIL重写器的东西。基于PostSharp，我经常能够在几个小时内编写一个非常具体的方面。

所以，回到你的问题，当然还有我自己的biais，我会说：如果你想写一个混淆器，合并/收缩器等等，而不是单独去Mono.Cecil或Microsoft.CCI因为他们的许可证比PostSharp更友好。但是，如果只是想开发一个自定义方面，使用PostSharp将使您保存周，如果您计划重新分发PostSharp，您会对我们可以提供的商业条件感到惊讶。