... 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.
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.
