Szenarien für Add-In-Pipelines
Aktualisiert: November 2007
Das Objektmodell für Add-In-Pipelines bietet Hostanwendungen und Add-Ins die Flexibilität, auf folgende Weisen zusammenzuarbeiten:
Abwärtskompatibilität. Neuere Versionen der Hosts oder Add-Ins können mit ihren älteren Äquivalenten zusammenarbeiten.
Isolation Sie können eines oder mehrere Add-Ins in eine Anwendungsdomäne im Hostprozess oder in einen isolierten Prozess verschieben.
Freigabe. Sie können ein Add-In in mehreren Kommunikationspipelines verwenden.
In der folgenden Abbildung wird eine einfache Kommunikationspipeline mit den zugehörigen Segmenten dargestellt.
Standardkommunikationspipeline
Abwärtskompatibilität
Es gibt zwei Szenarien zur Veranschaulichung der Abwärtskompatibilität.
Neuer Host, alte Add-Ins
In der folgenden Abbildung wird verdeutlicht, wie ein neuer Host mit einem älteren Add-In zusammenarbeiten kann.
Kommunikationspipeline mit neuem Host und altem Add-In
In diesem Szenario für die Abwärtskompatibilität kann der neue Host (Host v2) mit einem alten Add-In (Add-In v1) eingesetzt werden, da sein Add-In-seitiger Adapter (Add-In-seitiger Adapter v1->v2) die Typen in ein Format konvertiert, das vom alten Add-In erkannt wird.
Das neue Add-In (Add-In v2) verfügt über eigene Ansichts- und Adaptersegmente für die Kommunikation mit dem neuen Host.
Alter Host, neue Add-Ins
In der folgenden Abbildung wird verdeutlicht, wie ein alter Host mit neuen Add-Ins zusammenarbeiten kann.
Kommunikationspipeline mit altem Host und neuem Add-In
In diesem Szenario für die Abwärtskompatibilität kann das neue Add-In (Add-in v2) mit dem alten Host (Host v1) eingesetzt werden, da sein Add-In-seitiger Adapter (Add-In-seitiger Adapter v2->v1) die Typen in ein Format konvertiert, das vom alten Host erkannt wird.
Unterschiedliche Isolationsgrade
Sie können Add-Ins in einer neuen Prozess- oder Anwendungsdomäne aktivieren, indem Sie die entsprechenden Überladungen der Activate-Methode verwenden. Diese Isolation ist möglicherweise aus den folgenden Gründen notwendig:
Zur Bewältigung von Situationen, in denen sich die Hostanwendung ändert und die neuen Abhängigkeiten nicht von den älteren Add-Ins verwendet werden können. Dies könnte beispielsweise der Fall sein, wenn die Hostanwendung auf eine neue Version von .NET Framework aktualisiert wird.
Für mehr Zuverlässigkeit durch Ausführen des Add-Ins in einem eigenen Prozess.
Erstellen einer Sandbox für das Add-In. Eine Hostanwendung und ein Add-In verfügen beispielsweise über unterschiedliche Vertrauensebenen, die in der AddInSecurityLevel-Enumeration angegeben sind.
In der folgenden Abbildung wird eine Kommunikationspipeline mit zwei Add-Ins dargestellt, von denen eines in einem isolierten Prozess enthalten ist. In der Abbildung stellt OOP den isolierten Prozess dar.
Kommunikationspipeline mit isoliertem Add-In
In diesem Szenario verfügt ein Pipelineentwickler über zwei verschiedene Versionen des Vertrags und der Adapter: eine wurde für die anwendungsdomänenübergreifende Kommunikation und die andere für die prozessübergreifende Kommunikation optimiert. Die Unterschiede müssen weder von den Add-Ins noch vom Host wahrgenommen werden, da sie unabhängig vom Vertrag und dem Isolationsgrad weiterhin dieselben Ansichten verwenden.
Freigegebene Add-Ins
Ein Add-In kann für mehrere Hosts eingesetzt werden, solange es mit den Hosts kompatibel ist. Beispielsweise können Sie ein freigegebenes Add-In verwenden, um eine Symbolleiste zu implementieren, die eine Internetsuchfunktion für eine Hostwebanwendung bereitstellt. Ein weiteres Beispiel ist ein freigegebenes Add-In, das Spamfilter und Virenschutz für E-Mail-Server oder E-Mail-Clients bietet.
Damit das Add-In mit dem neuen Host zusammenarbeiten kann, müssen Sie einen neuen Add-In-seitigen Adapter erstellen, der eine Konvertierung von der Add-In-Ansicht zum Hostvertrag durchführt.
In der folgenden Abbildung wird verdeutlicht, wie ein Add-In (Add-In A) von zwei Hostanwendungen (Host A und Host B) gemeinsam genutzt werden kann.
Kommunikationspipeline mit freigegebenem Add-In