Mono Cecil vs PostSharp Core vs. Microsoft CCI für die Implementierung von AOP-Framework

Question

Welche ist besser in Bezug auf Funktionen, einfach zu bedienen, Dokumentation, Beispiele, Community/Support, VS-Integration, bekannte Implementierungen, langfristige Rentabilität und Geschwindigkeit aufbauen, um ein benutzerdefiniertes AOP-Framework zu implementieren?

Ich werde mit beginnen, was ich weiß (ich habe nur versucht, Postsharp zu bisher):

• Microsoft Common Compiler Instrastruture (CCI): Ich habe gelesen, dass für FxCop verwendet wird , ILMerge, SpeC# und Code Contracts. Es scheint sehr niedrig zu sein as it does not even take care of correcting offsets for branch codes that are borken when IL is modified with it.
• Postsharp 5 Jahre alt ist, hat viele Funktionen für die AOP (zB Abstracts einige Dinge, die Sie müssten haben manuell mit IL entfernt), Quelle Code zur Verfügung, entwickelt/unterstützt nur von einem Kerl aber er plant, auf dies ein Geschäft zu machen, hat Dokumentation könnte aber besser sein, baut etwa doppelt so lange dauern, sehr wenig Proben, wie IL zu injizieren und Version 2.0 wird in Kürze freigegeben werden, die viel zu werden versprechen verbessert.
• Mono Cecil: Geschrieben von einem Mann, Teil der Mono-Suite und es gibt einen Plug-in für Reflektor genannt REFLEXIL , die Mono Cecil verwendet.

Answer 1

Sowohl Microsoft.CCI als auch Mono.Cecil sind Low-Level und validieren keine produzierten Baugruppen. Es braucht viel Zeit, um den Grund für das Problem zu finden, wenn ein Fehler in der generierten Code- oder Assembly-Struktur vorliegt.
Ich würde die Verwendung von PostSharp empfehlen, wenn die Funktionen für Ihre Aufgaben ausreichen.
Sonst ... Mono.Cecil hat ein besseres, verständlicheres und benutzerfreundlicheres Objektmodell. Allerdings hatte ich einen hässlichen Fehler, wenn ich ihn in meinem Programm verwendete (der Verweis auf die falsche Methode wurde in der Assembly gespeichert; ich glaube, es gab einen Fehler bei der Verarbeitung von Metadaten-Token) Microsoft.CCI hat ein hässliches, völlig überdimensioniertes Objekt Modell in der gleichen Zeit ohne viele einfache Funktionen; es ist jedoch reifer als Mono.Cecil. Schließlich gab ich Mono.Cecil auf und verwendete Microsoft.CCI für mein Programm.

Answer 2

Wie bei den meisten Frameworks, die bereits sind da draußen, würde ich Ihnen vorschlagen, in Bezug auf Ihre eigenen AOP Rahmen der Umsetzung: nicht tun Sie es. Es gibt einige bereits da draußen, darunter (bald) kommerziell unterstützt PostSharp, und CThru, ein AOP-Framework von Typemock angetrieben.

Aber wie auch immer, ich fand Mono.Cecil sehr einfach zu bedienen. Es abstrahiert die Notwendigkeit, sich mit Reflection.Emit gut zu befassen, und es hat die Unterstützung der Mono-Community.

Ich schlage vor, Sie sehen LinFu - es ist eine Open-Source-Reihe von Bibliotheken, eine von ihnen ist ein AOP-Framework auf Mono.Cecil implementiert. Es gibt einen schönen Artikel über LinFu AOP auf CodeProject.

Answer 3

AFAIK, LinFu ist auf Mono.Cecil gebaut.

Ich würde sagen, dass PostSharp.Core hat mehr High-Level-Features als andere Frameworks, so dass es für größere Arbeiten weniger schwierig ist. Sie können auch auf niedriger Ebene arbeiten, aber nicht auf binärer Ebene (von Entwurf). Sie könnten einen Assembly Merger/Shriner mit PostSharp erstellen, aber die Tatsache, dass es mit ILASM zurück kompiliert, würde einige Einschränkungen (zum Beispiel, dass sogar interne Mitglieder benannt werden sollten). Auf der anderen Seite ist es mit ILASM als Backend viel einfacher, auf der Oberseite von PostSharp zu entwickeln, da ILASM viele Regeln überprüft und Sie den produzierten MSIL-Code leicht lesen können. Mit PostSharp können Sie sogar Kommentare in MSIL einfügen, um das Debuggen der Code-Generierung zu erleichtern.

Ein weiterer Punkt: Wenn Sie einen benutzerdefinierten Aspekt (z. B. entwickeln Sie eine Datenbank-Engine und möchten einen Persistenzaspekt liefern wollen), brauchen Sie viel mehr als nur einen MSIL-Rewriter. Sie benötigen eine AO-Infrastruktur, die einen Großteil der Arbeit für Sie erledigt. Wenn Sie einen benutzerdefinierten Aspekt entwickeln, würde ich sagen, 1% der Arbeit ist spezifisch für Ihren benutzerdefinierten Aspekt, 39% ist die Aspekt-Infrastruktur und 60% ist der MSIL-Rewriter. Oft kann ich in wenigen Stunden anhand von PostSharp einen ganz bestimmten Aspekt programmieren.

Also, zurück zu Ihrer Frage, und natürlich mit meinen eigenen biais, würde ich sagen: Wenn Sie einen Obfuscator, Merger/Shroker und so weiter schreiben möchten, gehen Sie lieber für Mono.Cecil oder Microsoft.CCI Einziger Grund, dass ihre Lizenz freundlicher ist als die von PostSharp. Aber wenn Sie nur einen benutzerdefinierten Aspekt entwickeln möchten, wird die Verwendung von PostSharp Sie sparen Wochen, und Sie würden von kommerziellen Bedingungen überrascht sein, die wir bieten könnten, wenn Sie planen, PostSharp neu zu verteilen.