... Das Managed Add-in Framework vereint die Vorteile der genannten Verfahren und meidet aber deren Schwächen. Die Klasse AddInStore übernimmt den gesamten Vorgang des Auffindens von Addins und stellt die Metadaten eines Add-ins als AddInToken zur Verfügung.
AddInStore.Update(path);IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(AddInType), path);
Der Aufruf AddInStore.Update() durchsucht den angegebenen Pfad rekursiv nach möglichen Add-ins in allen Assemblies. Es werden alle öffentlichen Klassen gefunden, die mit dem Attribut [AddIn] markiert sind. Das Attribut erlaubt dem Add in-Entwickler zusätzliche Informationen für den Host mit anzugeben: Name, Version, Herausgeber und Beschreibung. Die Metadaten aller Add-ins werden extrahiert und automatisch in zwei Dateien gespeichert: PipelineComponents.store und AddIns.store.
Die Klasse AddInStore verwaltet somit einen Cache der installierten Add-ins, der lediglich im Bedarfsfall aktualisiert werden muss. Über AddInStore.Rebuild() können Änderungen gegenüber dem alten Stand abgefragt werden. Außerdem steht im kommenden .NET Framework 3.5 zukünftig das neue Kommandozeilenprogramm AddInTool.exe bereit, welches dazu verwendet wird, während der Verteilung von Add-ins den Cache von AddInStore zu aktualisieren und dadurch bereits den ersten Start der Anwendung zu beschleunigen.
Add-ins aktivieren
Die anschließende Aktivierung von Addins gestaltet sich ebenfalls sehr einfach. Ein gefundenes AddInToken beinhaltet alle Informationen und Metadaten, um das Add-in mit einem einzigen Aufruf zu aktivieren:
AddInType addIn = token.Activate<AddInType>(AddInSecurityLevel.Internet);
Zur Gewährleistung von Sicherheit und Stabilität der Host-Anwendung und der einzelnen Add-ins untereinander wird zusammen mit diesem Aufruf eine vordefinierte Sicherheitsstufe angegeben oder alternativ ein eigenes Code Access Security-PermissionSet. Zur vollständigen Isolation von Add-ins und für die Möglichkeit, geladene Add-in-Assemblies auch wieder zu entladen, sollten Add-ins in eine separate Anwendungsdomäne geladen werden. Das Managed Add-in-Framework bewerkstelligt dies automatisch und bietet dabei ebenfalls noch andere Kombinationen an: Add-ins werden in die Anwendungsdomäne des Hosts geladen, alle Add-ins landen in der gleichen separaten Anwendungsdomäne, jedes Add-in erhält seine eigene Anwendungsdomäne, alle Add-ins werden in eine Anwendungsdomäne eines externen Prozesses geladen oder jedes Add-in hat seine eigene Anwendungsdomäne in einem externen Prozess. Die komfortable Nutzung externer Prozesse für das Add-in-Hosting stellt eine interessante Alternative dar, die vom Host-Entwickler zukünftig ohne zusätzlichen Aufwand genutzt werden kann.
Das Laden und Aktivieren von Addins war mit den bisherigen Möglichkeiten des .NET Framework aus Sicherheitsaspekten besonders heikel: Durch entsprechend manipulierte Konstruktoren und Exceptions mit eigenen Serialisierungsmechanismen konnte ein gutgläubiger Lademechanismus unter Umständen hintergangen werden. Diese Details bleiben dem Host-Entwickler erfreulicherweise in der Zukunft erspart.
Mit Add-ins kommunizieren
Die bislang vorgestellten Merkmale des Managed Add-in Frameworks zielen vor allem auf eine gute Performance der Addin- Lösung und reduzieren den Aufwand bei deren Entwicklung. Die Sache mit dem Aufwand relativiert sich beim Thema Addin Pipeline zunächst, denn die anfängliche Hürde zur Einhaltung der geforderten Strukturen ist recht hoch. Mittelfristig gesehen zahlen sich die Maßnahmen jedoch aus. Die Leitgedanken hinter der so genannten Add-in Pipeline sind zum einen die optimale Entkopplung von Host und Add-in, andererseits die Kompatibilität von Host und Add-ins über verschiedene Versionen hinweg.
Die Add-in Pipeline ist das symmetrische Kommunikationsmodell zwischen Host und Add-in, das den Austausch von Daten und Nachrichten erlaubt. Sie besteht aus mehreren Komponenten, die teilweise in die Add-in-Anwendungsdomäne, teilweise in die AppDomain des Hosts geladen werden. Eine Übersicht dieser Komponenten gibt Abbildung 1:
Alle Komponenten der Pipeline müssen als eigene Assemblies definiert und in speziell benannten Unterverzeichnissen zum Pipeline Wurzelverzeichnis gespeichert werden. ...
