System-AddIn

… 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 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(
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:

Abb. 1: Die Managed Add-in-Pipeline (Quelle: MSDN Online-Dokumentation)

Alle Komponenten der Pipeline müssen
als eigene Assemblies definiert und in speziell
benannten Unterverzeichnissen zum
Pipeline Wurzelverzeichnis gespeichert
werden. …

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.