Mono Cecil vs. PostSharp de base par rapport à Microsoft CCI pour la mise en œuvre cadre AOP

Question

Quelle est la meilleure en termes de capacités, la facilité d'utilisation, la documentation, des échantillons, communauté / support, intégration VS, les implémentations connues, la viabilité à long terme et construire la vitesse pour mettre en œuvre un cadre AOP personnalisé?

Je vais commencer par ce que je sais (je n'ai essayé PostSharp à ce jour):

• Microsoft Common compilateur Instrastruture (CCI) : J'ai lu que est utilisé pour FxCop, ILMerge, Spec # et Contrats Code. Il semble être très faible niveau car il ne prend même pas soin de corriger les décalages pour des codes de branchement qui sont borken quand iL est modifié avec elle .
• PostSharp est de 5 ans, a beaucoup capacités d'AOP (par exemple résumés certaines choses que vous devez avoir à faire manuellement avec l'IL loin), la source Code disponible, développé / supporté par un seul gars, mais il prévoit de ce qui en fait une entreprise, a documentation, mais pourrait être mieux, builds prendre environ deux fois plus longtemps, très petits échantillons sur la façon d'injecter IL et la version 2.0 sera bientôt publié qui promet d'être beaucoup améliorée.
• Mono Cecil : Écrit par un gars, une partie de la suite Mono et il y a un plug-in pour le réflecteur appelé Reflexil qui utilise Mono Cecil.

Answer 1

Les deux Microsoft.CCI et Mono.Cecil sont de bas niveau, et ne valident pas les assemblages produits. Il faut beaucoup de temps pour trouver la raison du problème, s'il y a une erreur dans le code généré ou structure d'assemblage.
Je vous recommande d'utiliser PostSharp si ses caractéristiques sont assez pour les tâches.
Sinon ... Mono.Cecil a mieux, plus compréhensible et facile dans le modèle d'objet d'utilisation. Cependant, j'ai eu un bug laid quand il est utilisé dans mon programme (référence à la mauvaise méthode a été enregistrée dans l'ensemble, je pense qu'il y avait un bug avec les métadonnées jetons de manutention)
Microsoft.CCI a un modèle laid, objet tout à fait sur, le tout en même temps manque de nombreuses fonctionnalités simples; cependant, il est plus mature que Mono.Cecil. Enfin, j'abandonné Mono.Cecil et utilisé Microsoft.CCI pour mon programme.

Answer 2

Comme la plupart des cadres qui sont déjà là-bas, je vous dirais, en ce qui concerne la mise en œuvre de votre propre cadre AOP: Ne pas le faire . Il y a plusieurs déjà là-bas, y compris (bientôt à être) pris en charge dans le commerce PostSharp, et CThru , un cadre AOP alimenté par Typemock .

Mais de toute façon, j'ai trouvé Mono.Cecil très facile à utiliser. Il fait abstraction de la nécessité de traiter Reflection.Emit bien, et il a le soutien de la communauté Mono.

Je vous suggère de jeter un oeil à Linfu - c'est un ensemble open-source les bibliothèques, l'un d'entre eux est un cadre d'AOP mis en œuvre au-dessus de Mono.Cecil. Il y a un bel article sur Linfu AOP sur CodeProject.

Answer 3

AFAIK, Linfu est construit sur Mono.Cecil.

Je dirais que PostSharp.Core a plus de fonctionnalités de haut niveau que les autres cadres, il est donc moins difficile à utiliser pour les travaux plus importants. Vous pouvez travailler à un niveau bas aussi, mais pas au niveau binaire (par la conception). Vous pouvez faire une fusion assemblage / shrinker utilisant PostSharp, mais le fait qu'il compile arrière à l'aide ILASM définirait des limites (par exemple que même les membres internes doivent être nommés). De l'autre côté, ayant ILASM comme backend rend beaucoup plus facile de se développer sur le haut de PostSharp, depuis ILASM vérifier de nombreuses règles et vous pouvez facilement lire le code MSIL produit. PostSharp vous permettent même de mettre des commentaires dans MSIL pour aider à corriger la génération de code.

Un autre point: si vous voulez faire un aspect personnalisé (par exemple, vous développez un moteur de base de données et que vous voulez offrir un aspect de persistance), vous avez besoin beaucoup plus qu'un simple rewriter MSIL. Vous avez besoin d'une infrastructure AO qui fera une grande partie du travail pour vous. Lorsque vous développez un aspect personnalisé, je dirais que 1% du travail est spécifique à votre aspect personnalisé, 39% est l'infrastructure d'aspect, et 60% est la substance de rewriter MSIL. Je suis souvent en mesure de programmer un aspect très spécifique dans quelques heures sur la base PostSharp.

Alors, revenir à votre question, et bien sûr avec mes propres Biais, je dirais: si vous voulez écrire un obfuscateur, fusion / shrinker et ainsi de suite, plutôt aller pour Mono.Cecil ou Microsoft.CCI pour la seule raison pour laquelle leur licence si plus convivial que celui de PostSharp. Mais si vous voulez juste de développer un aspect personnalisé en PostSharp vous fera gagner, et vous seriez surpris semaines par des conditions commerciales que nous pourrions offrir si vous prévoyez de redistribuer PostSharp.