Mono Cecil vs. PostSharp Core vs. Microsoft CCI para implementar el marco AOP

Question

Cuál es el mejor en términos de capacidades, fácil de usar, documentación, ejemplos, comunidad/soporte, integración VS, implementaciones conocidas, viabilidad a largo plazo y velocidad de construcción para implementar un marco AOP personalizado

Voy a empezar con lo que sé (solo he probado a PostSharp hasta ahora):

• Microsoft Común Compilador Instrastruture (CCI): He leído que se utiliza para FxCop , ILMerge, SpeC# y Contratos de código. Parece ser de muy bajo nivel as it does not even take care of correcting offsets for branch codes that are borken when IL is modified with it.
• PostSharp es de 5 años de edad, tiene muchos capacidades para AOP (por ejemplo, resúmenes algunas cosas que tendría que tener a hacer manualmente con IL distancia), fuente últimas informaciones, desarrollado/apoyado por un solo hombre pero él está planeando en haciendo de este un negocio, tiene documentación, pero podría ser mejor, construye tomar el doble de tiempo, muy pequeñas muestras sobre cómo inyectar IL y la versión 2.0 será lanzado pronto que promete ser mucho mejorado.
• Mono Cecil: Escrito por un hombre, que forma parte de la suite Mono y hay una plug-in para Reflector llamados Reflexil que utiliza Mono Cecil.

Answer 1

Tanto Microsoft.CCI como Mono.Cecil son de bajo nivel y no validan ensamblajes producidos. Lleva mucho tiempo encontrar la razón del problema, si hay algún error en el código generado o en la estructura del ensamblaje.
Recomendaría utilizar PostSharp si sus funciones son suficientes para sus tareas.
De lo contrario ... Mono.Cecil tiene un modelo de objeto mejor, más comprensible y fácil de usar. Sin embargo, tuve un error feo cuando lo usé en mi programa (la referencia al método incorrecto se guardó en el ensamblado, creo que hubo algún error con el manejo de los tokens de metadatos)
Microsoft.CCI tiene un objeto feo, completamente sobre diseñado modelo al mismo tiempo que carece de muchas características simples; sin embargo, es más maduro que Mono.Cecil. Finalmente, abandoné Mono.Cecil y usé Microsoft.CCI para mi programa.

Answer 2

Al igual que con la mayoría de los marcos que ya están ahí fuera, sugeriría a usted, con respecto implementación de su propio marco de AOP: No practico. Ya hay varios disponibles, incluido PostSharp (que pronto será comercial) y CThru, un marco AOP con Typemock.

Pero de todos modos, encontré Mono.Cecil muy fácil de usar. Se abstrae la necesidad de tratar bien con Reflection.Emit, y cuenta con el apoyo de la comunidad Mono.

Sugiero que eche un vistazo a LinFu - es un conjunto de librerías de código abierto, una de ellas es un marco AOP implementado encima de Mono.Cecil. Hay un buen artículo en LinFu AOP en CodeProject.

Answer 3

AFAIK, LinFu está basado en Mono.Cecil.

Yo diría que PostSharp.El núcleo tiene más características de alto nivel que otros marcos, por lo que es menos difícil de usar para trabajos más grandes. También puede trabajar a bajo nivel, pero no a nivel binario (por diseño). Podría hacer una fusión/reducción de ensamblaje utilizando PostSharp, pero el hecho de que compila de nuevo usando ILASM establecería algunas limitaciones (por ejemplo, incluso los miembros internos deberían ser nombrados). Por otro lado, tener ILASM como backend hace que sea mucho más fácil desarrollarlo en la parte superior de PostSharp, ya que ILASM verifica muchas reglas y puede leer fácilmente el código MSIL producido. PostSharp incluso te permite poner comentarios en MSIL para ayudar a la generación de errores de depuración.

Otro punto: si desea hacer un aspecto personalizado (por ejemplo, desarrolla un motor de base de datos y desea proporcionar un aspecto persistente), necesita mucho más que un regrabador MSIL. Necesita una infraestructura AO que hará gran parte del trabajo por usted. Cuando desarrolle un aspecto personalizado, diría que el 1% del trabajo es específico para su aspecto personalizado, el 39% es la infraestructura de aspecto y el 60% es el material de reescritura de MSIL. A menudo puedo programar un aspecto muy específico en un par de horas basado en PostSharp.

Por lo tanto, volviendo a su pregunta, y por supuesto con mi propia biais, diría: si usted quiere escribir un ofuscador, fusión/encogimiento y así sucesivamente, en lugar de ir a Mono.Cecil o Microsoft.CCI para el solo razón de que su licencia sea más amigable que la de PostSharp. Pero si solo desea desarrollar un aspecto personalizado, usar PostSharp lo hará guardar semanas, y le sorprenderían las condiciones comerciales que podríamos ofrecerle si planea redistribuir PostSharp.