就功能、易用性、文档、示例、社区/支持、VS 集成、已知实现、长期可行性和实现自定义 AOP 框架的构建速度而言，哪个更好？
我将从我所知道的开始（到目前为止我只尝试过 PostSharp）：
- Microsoft Common Compiler
Instrastruture (CCI)：我读过
用于 FxCop、ILMerge、Spec# 和
代码合同。它似乎非常低级别 因为它甚至不考虑纠正偏移量对于用它修改 IL 时中断的分支代码。
- PostSharp已有5年历史，拥有许多
AOP 的功能（例如摘要
有些事情你需要做
手动执行 IL 操作），来源
代码可用、开发/支持
只有一个人，但他正在计划
使这成为一项业务，
文档但可以更好，
构建时间大约是原来的两倍，非常
关于如何注射 IL 的小样本
并且2.0版本即将发布
这有望得到很大改善。
- Mono Cecil：由一个人撰写，部分
Mono 套件的并且有一个
Reflector 插件 Reflexil
使用 Mono Cecil。
Which is the better in terms of capabilities, easy of use, documentation, samples, community/support, VS integration, known implementations, long-term viability, and build speed to implement a custom AOP framework?
I'll start with what I know (I have only tried PostSharp to so far):
- Microsoft Common Compiler
Instrastruture (CCI): I've read that
is used for FxCop, ILMerge, Spec# and
Code Contracts. It seems to be very low level as it does not even take care of correcting offsets for branch codes that are borken when IL is modified with it.
- PostSharp is 5 years old, has many
capabilities for AOP (e.g. abstracts
some things you would need to have to
do manually with IL away), source
code available, developed/supported
by only one guy but he is planning on
making this a business, has
documentation but could be better,
builds take about twice as long, very
little samples on how to inject IL
and version 2.0 will be released soon
which promises to be much improved.
- Mono Cecil: Written by one guy, part
of the Mono suite and there is a
plug-in for Reflector called Reflexil
that uses Mono Cecil.
发布评论
评论（3）
Microsoft.CCI 和 Mono.Cecil 都是低级的，并且不验证生成的程序集。如果生成的代码或汇编结构有任何错误，则需要花费大量时间来查找问题原因。
如果 PostSharp 的功能足以满足您的任务，我建议使用它。
否则... Mono.Cecil 有更好、更容易理解和易于使用的对象模型。但是，在我的程序中使用它时，我遇到了一个丑陋的错误（对错误方法的引用保存在程序集中；我认为元数据标记处理存在一些错误）
Microsoft.CCI 有一个丑陋的、完全过度设计的对象模型，同时缺乏许多简单的功能；然而，它比 Mono.Cecil 更成熟。最后，我放弃了 Mono.Cecil，并在我的程序中使用了 Microsoft.CCI。
Both Microsoft.CCI and Mono.Cecil are low-level, and don't validate produced assemblies. It takes lots of time to find the reason of problem, if there is any error in generated code or assembly structure.
I'd recommend using PostSharp if it's features are enough for you tasks.
Otherwise... Mono.Cecil has better, more understandable and easy in use object model. However, I had an ugly bug when used it in my program (reference to the wrong method was saved in the assembly; I think there was some bug with metadata tokens handling)
Microsoft.CCI has an ugly, utterly over-designed object model in the same time lacking many simple features; however, it's more mature than Mono.Cecil. Finally, I abandoned Mono.Cecil and used Microsoft.CCI for my program.
与大多数现有框架一样，关于实现您自己的 AOP 框架，我建议您：不要这样做。已经有几个，包括（即将）商业支持的 PostSharp 和 CThru，一个由 Typemock 提供支持的 AOP 框架。
但无论如何，我发现 Mono.Cecil 非常容易使用。它很好地抽象了处理
Reflection.Emit的需要，并且得到了 Mono 社区的支持。我建议您查看 LinFu - 这是一组开源库，一个其中一个是在Mono.Cecil之上实现的AOP框架。 CodeProject 上有一篇关于 LinFu AOP 的好文章。
As with most frameworks that are already out there, I would suggest to you, regarding implementing your own AOP framework: Don't do it. There are several already out there, including (soon-to-be) commercially supported PostSharp, and CThru, an AOP framework powered by Typemock.
But anyway, I found Mono.Cecil very easy to use. It abstracts away the need to deal with
Reflection.Emitnicely, and it has the support of the Mono community.I suggest you have a look at LinFu - it's an open-source set of libraries, one of them is an AOP framework implemented on top of Mono.Cecil. There is a nice article on LinFu AOP on CodeProject.
AFAIK，LinFu 是基于 Mono.Cecil 构建的。
我想说的是，PostSharp.Core 比其他框架具有更多高级功能，因此用于大型作品的难度较小。您也可以在低级别工作，但不能在二进制级别（根据设计）。您可以使用 PostSharp 进行程序集合并/收缩，但它使用 ILASM 编译回来的事实会设置一些限制（例如，即使是内部成员也应该被命名）。另一方面，使用 ILASM 作为后端使得在 PostSharp 之上进行开发变得更加容易，因为 ILASM 验证了许多规则，并且您可以轻松阅读生成的 MSIL 代码。 PostSharp 甚至允许您将注释添加到 MSIL 中以帮助调试代码生成。
另一点：如果您想做一个自定义方面（例如，您开发一个数据库引擎并希望提供一个持久性方面），您需要的不仅仅是一个 MSIL 重写器。您需要一个 AO 基础设施来为您完成大部分工作。当您开发自定义方面时，我想说 1% 的工作特定于您的自定义方面，39% 是方面基础设施，60% 是 MSIL 重写器。我通常能够基于 PostSharp 在几个小时内编写一个非常具体的方面。
所以，回到你的问题，当然，带着我自己的偏见，我会说：如果你想编写一个混淆器、合并/收缩器等，最好选择 Mono.Cecil 或 Microsoft.CCI，因为它们的唯一原因是如果比 PostSharp 的许可证更友好的话。但如果只是想开发一个自定义方面，使用 PostSharp 将使您节省几周，并且如果您计划重新分发 PostSharp，您会对我们可以提供的商业条件感到惊讶。
AFAIK, LinFu is built on Mono.Cecil.
I would say that PostSharp.Core has more high-level features than other frameworks, so it's less difficult to use for larger works. You can work at low level too, but not at binary level (by design). You could do an assembly merger/shrinker using PostSharp, but the fact that it compiles back using ILASM would set some limitations (for instance that even internal members should be named). On the other side, having ILASM as the backend makes it much easier to develop on the top of PostSharp, since ILASM verify many rules and you can easily read the produced MSIL code. PostSharp even let you put comments into MSIL to help debugging code generation.
Another point: if you want to do a custom aspect (for instance, you develop a database engine and want to deliver a persistence aspect), you need much more than just an MSIL rewriter. You need an AO infrastructure that will do much of the job for you. When you are developing a custom aspect, I would say 1% of the work is specific to your custom aspect, 39% is the aspect infrastructure, and 60% is the MSIL rewriter stuff. I am often able to program a very specific aspect in a couple of hours based on PostSharp.
So, back to your question, and of course with my own biais, I would say: if you want to write an obfuscator, merger/shrinker and so on, rather go for Mono.Cecil or Microsoft.CCI for the only reason that their license if more friendly than PostSharp's one. But if just want to develop a custom aspect, using PostSharp will make you save weeks, and you would be surprised by commercial conditions we could offer if you plan to redistribute PostSharp.