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

Siehe auch

Konzepte

Pipeline-Entwicklung