System-AddIn

… Wenn Host und Add-in in unterschiedliche
Anwendungsdomänen geladen
werden, findet die Kommunikation über
.NET Remoting statt. Der Übergang von
einer Anwendungsdomäne zur anderen
bildet eine Remoting-Grenze und gleichzeitig
die Isolationsschicht zwischen
Host und Add-in. Auf beiden Seiten dieser
Grenze steht ein Kommunikationsvertrag,
der Contract. Das Interface, das
den Contract bildet, muss von IContract
abgeleitet sein und mit dem AddInContractAttribute
markiert werden. Die Contract-
Assembly benötigt dazu Referenzen
auf die Assemblies System.AddIn.Contract und System.AddIn.Pipeline. Sie
muss zudem im Unterverzeichnis „Contracts“
der Pipeline abgelegt werden. Auch
für die anderen Komponenten der Pipeline
gelten ähnliche Anforderungen bezüglich
Basisklassen oder Interfaces, Verwendung
von Custom Attributes, Assembly-Referenzen
und Speicherorten. Die Beispielanwendung
auf der Heft-CD und die Online-
Dokumentation geben hier weiteren
Aufschluss.

Bezüglich der Implementierung von
Contracts existieren zusätzlich strenge
Vorgaben. Ein Contract ist die einzige
Komponente der Add-in Pipeline, die sich
während der Lebenszeit der Anwendung
möglichst niemals verändern sollte. Alle
im Contract übergebenen Klassen müssen
entweder serialisierbar sein (Marshal
by value
) oder durch Ableiten von
MarshalByRefObject remoting-fähig
gemacht werden. Zudem unterstützt das
Contract Interface ausschließlich Methoden,
jedoch keine Properties. Diese
Einschränkung wurde im Hinblick auf
Contracts der Windows Communication
Foundation (WCF) getroffen: Host und
Add-in könnten so zukünftig gegebenenfalls
auch über WCF kommunizieren.
Die beiden View-Komponenten (Add
In-View
und Host View) der Add-in Pipe-
line
werden als abstrakte Klassen, ohne
Referenzen auf andere Objekte realisiert.
Jede View definiert also die Sicht, die
Add-in oder Host auf die jeweils gegenüberliegende
Seite haben – Properties sind
hierbei wieder erlaubt. Die Vermittlung
zwischen Contract und View übernehmen
auf beiden Seiten der Pipeline jeweils Adapter-
Komponenten. Entsprechend der
Reihenfolge, in der die Objekte erzeugt
werden, erbt ein Host-seitiger Adapter
von der View-Komponente und erhält
eine Contract-Instanz als Parameter im
Konstruktor. Ein Add-in-seitiger Adapter
erbt dagegen vom Contract und erhält
eine Instanz der View als Parameter. Beide
Adapter-Komponenten können so zwischen
Contract und View übersetzen. Bei
Änderungen auf Seiten des Add-ins oder
des Hosts können mehrere Adapter parallel
zum Einsatz kommen, um zwischen
alten und neuen Versionen entsprechend
zu vermitteln. Auch die Anpassung eines
Hosts an ganz neue Arten von Add-ins
oder die Anpassung von Add-ins an neue
Hosts ist hiermit möglich. Am Ende der
Pipeline steht jeweils ein Host oder ein
Add-in, das keinerlei Informationen zur
Implementierung der anderen Seite benötigt.

Die beschriebene Add-in Pipeline stellt
relativ strenge Anforderungen an Struktur
und Verteilung der beteiligten Komponenten.
Es dauert daher vielleicht einige
Zeit, bis man sich mit dieser Abstraktion
vertraut gemacht hat. Für das Design
eines sinnvollen Contracts ist zusätzlich
einige Erfahrung nötig, der Vergleich mit
existierenden Add-in Contracts anderer
Projekte ist sinnvoll. Als Beispiel hierfür
kann das Open Source-Projekt Paint.NET
dienen: In einer Serie von Blog-Einträgen
wird die Umgestaltung der existierenden
Add-in-Schnittstellen in Richtung System.AddIn beschrieben [4].

Gerade im Bereich der Add-in-Pipeline
könnten zusätzliche Werkzeuge für
Visual Studio hilfreich sein, die dabei
helfen die notwendige Projektstruktur
zu erzeugen, Add-ins automatisch in
die richtigen Verzeichnisse zu verteilen,
etc. Für das kommende Visual Studio
2008 sind allerdings bislang keine entsprechenden
Projektvorlagen oder Assistenten
vorgesehen. Eine interessante
Veröffentlichung im Umfeld von Add in-
Technologien ist allerdings VSTA.

Visual Studio Tools for Applications (VSTA)

Bei VSTA handelt es sich um ein Produkt und SDK zur Erstellung erweiterbarer Anwendungen
[5]. Mit VSTA können eigene .NET- oder COM-Anwendungen um ein flexibles Add-in-Modell erweitert
werden, das funktional vergleichbar mit den Add-in-Fähigkeiten von Microsoft Office ist:
Wesentliche Features sind ein Makrorekorder und eine integrierbare, Visual Studio basierte IDE
zum Erstellen von Makros und Add-ins. VSTA bietet damit ein „Managed VBA“ für eigene Anwendungen
und teilt sich entsprechend auch die Codebasis mit den neueren Veröffentlichungen rund
um die Visual Studio Tools for Office (VSTO). Für die Verwendung von VSTA bzw. für das Verteilen
von VSTA basierten Anwendungen ist eine eigene Lizenz erforderlich. Die mitgelieferte generische
Pipeline erleichtert zwar den Einstieg, bietet aber entsprechend nur eine spät gebundene (engl.
„late-bound“) Kommunikation.
Das VSTA SDK wurde zeitgleich mit Microsoft Office 2007 veröffentlicht und enthielt bereits den
Namensraum System.AddIn in einer System.AddIn.dll mit der Versionsnummer 2.0. Im .NET Framework
3.5 wird die Versionsnummer dieser Assembly auf 3.5 angehoben. Das Managed Add-In
Framework
ergänzt hier insbesondere die Fähigkeiten zum Auffinden und Aktivieren von Add-ins.

Vereinfachte Add-in-Entwicklung dank eines Framework

Die Entwicklung erweiterbarer, modularer
Anwendungen wird durch das
Managed Add-in Framework erheblich
vereinfacht. Die notwendige Add-in
Pipeline
wirkt anfänglich vielleicht etwas
abschreckend, die dahinter liegenden
Konzepte und deren Vorteile werden aber
schnell klar. Einige der fortgeschrittenen
Themen wurden in diesem Artikel noch
ausgespart, wie etwa die Verwaltung der
Lebenszeit von Add-ins oder die Bereitstellung
eines Host-seitigen API für die
Verwendung durch Add-ins. Die Klassen
in System.AddIn und die dazugehörige
Dokumentation haben in diesen Bereichen
noch viel zu bieten.

Das Managed Add-in Framework
ist flexibel genug, um beliebige Add-in-Anwendungen zu erzeugen. Möglich
sind sehr eng definierte Schnittstellen
mit klarem Aufrufkontext und Verwendungszweck
eines Add-ins. Möglich
sind allerdings auch sehr offene, spät
gebundene Schnittstellen, vergleichbar
mit COM-Technologien. Add-in und
Host können sich dabei gegenseitig ein
umfangreiches API zur Verfügung stellen.
Die aktuelle Beta 1 von Visual Studio
2008 erhält genug Funktionalität
und Dokumentation, um bereits jetzt mit
dem Managed Add-in Framework loszulegen.
Mithilfe von Add-in-Technologien
können interne und externe Projekte auf
noch unbekannte Anforderungen vorbereitet
werden.

Jochen Reinelt arbeitet als Senior Consultant bei ILOG und ist Spezialist für Business Rule Management und .NET-Anwendungsentwicklung. Er beschäftigt sich seit vielen Jahren mit flexiblen Software Architekturen, verteilten Anwendungen und Application Frameworks.

Kommentare

Schreibe einen Kommentar

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