Freigeben über

Übersicht über WPF-Add-Ins

  • Artikel

Das .NET Framework ein Add-In-Modell, mit dem Entwickler Anwendungen erstellen können, die Add-In-Erweiterbarkeit unterstützen. Dieses Add-In-Modell ermöglicht die Erstellung von Add-Ins, die in die Anwendungsfunktionalität integriert werden und diese erweitern. In einigen Szenarien müssen Anwendungen auch Benutzeroberflächen anzeigen, die von Add-Ins bereitgestellt werden. In diesem Artikel wird gezeigt, wie WPF das .NET Framework-Add-In-Modell erweitert, um diese Szenarien, die zugrunde liegende Architektur, ihre Vorteile und ihre Einschränkungen zu unterstützen.

Voraussetzungen

Kenntnisse des Add-In-Modells von .NET Framework sind erforderlich. Weitere Informationen finden Sie unter Add-Ins und Erweiterbarkeit.

Übersicht über Add-Ins

Um das mit dem Integrieren neuer Funktionen verbundene erneute Kompilieren und Bereitstellen von Anwendungen zu vermeiden, da diese Vorgänge sehr komplex sind, sind Anwendungen mit Erweiterbarkeitsmechanismen ausgestattet. Diese ermöglichen Entwicklern (sowohl Erst- als auch Drittanbieter) das Erstellen anderer Anwendungen, die integriert werden können. Diese Art von Erweiterbarkeit wird in der Regel durch die Verwendung von Add-Ins (auch als „Add-Ons“ oder „Plug-Ins“ bezeichnet) unterstützt. Es folgen Beispiele für reale Anwendungen, die eine Erweiterbarkeit mit Add-Ins verfügbar machen:

  • Internet Explorer-Add-Ons

  • Windows Media Player-Plug-Ins

  • Visual Studio-Add-Ins

Beispielsweise können Drittanbieterentwickler mithilfe des Add-In-Modells von Windows Media Player „Plug-Ins“ implementieren, durch die der Windows Media Player auf vielfältige Weise erweitert wird. Dazu zählen das Erstellen von Decodern und Encodern für Medienformate, für die keine systemeigene Unterstützung durch Windows Media Player besteht (z. B. DVD, MP3), Audioeffekte und Skins. Jedes Add-In-Modell ist so aufgebaut, dass es die zu einer Anwendung gehörenden Funktionen verfügbar macht, obwohl verschiedene Entitäten und Verhaltensweisen für alle Add-In-Modelle gelten.

Die drei Hauptentitäten typischer Add-In-Erweiterbarkeitslösungen sind Verträge, Add-Ins und Hostanwendungen. Mit Verträgen wird auf zwei Arten definiert, wie Add-Ins mit Hostanwendungen integriert sind:

  • Add-Ins sind in Funktionen integriert, die von Hostanwendungen implementiert werden.

  • Hostanwendungen machen Funktionen verfügbar, in die Add-Ins integriert werden.

Damit Add-Ins verwendet werden können, müssen sie von Hostanwendungen gefunden und zur Laufzeit geladen werden. Daher sind Anwendungen, die Add-Ins unterstützen, zusätzlich für folgende Aufgaben verantwortlich:

  • Ermittlung: Suchen nach Add-Ins, die von Hostanwendungen unterstützte Verträge einhalten.

  • Aktivierung: Laden, Ausführen und Herstellen der Kommunikation mit Add-Ins.

  • Isolation: Verwenden von Anwendungsdomänen oder Prozessen zum Einrichten von Isolationsgrenzen, die Anwendungen vor möglichen Sicherheitsproblemen und Problemen bei der Ausführung von Add-Ins schützen.

  • Kommunikation: Durch das Aufrufen von Methoden und Übergeben von Daten können Add-Ins und Hostanwendungen über Isolationsgrenzen hinweg miteinander kommunizieren.

  • Verwaltung der Lebensdauer: Laden und Entladen von Anwendungsdomänen und -prozessen auf eine klare, vorhersehbare Weise (siehe Anwendungsdomänen).

  • Versionsverwaltung: Sicherstellen, dass Hostanwendungen und Add-Ins auch dann noch kommunizieren können, wenn neue Versionen erstellt wurden.

Letztlich ist es eine wichtige Aufgabe, ein stabiles Add-In-Modell zu entwickeln. Aus diesem Grund stellt das .NET Framework eine Infrastruktur zum Erstellen von Add-In-Modellen bereit.

Hinweis

Weitere Informationen zu Add-Ins finden Sie unter Add-Ins und Erweiterbarkeit.

Übersicht über das Add-In-Modell von .NET Framework

Das Add-In-Modell von .NET Framework, das im System.AddIn-Namespace vorkommt, enthält eine Reihe von Typen, mit denen die Entwicklung der Add-In-Erweiterbarkeit vereinfacht werden soll. Das grundlegende Element des Add-In-Modells von .NET Framework stellt der Vertrag dar. Dort ist festgelegt, wie eine Hostanwendung und ein Add-In miteinander kommunizieren. Ein Vertrag wird mit einer für Hostanwendungen spezifischen Ansicht des Vertrags für eine Hostanwendung verfügbar gemacht. Auf ähnliche Weise wird eine für Add-Ins spezifische Ansicht des Vertrags für das Add-In verfügbar gemacht. Ein Adapter ermöglicht es einer Hostanwendung und einem Add-In, zwischen ihren jeweiligen Ansichten des Vertrags miteinander zu kommunizieren. Verträge, Ansichten und Adapter werden als Segmente bezeichnet, und mehrere miteinander verbundene Segmente stellen eine Pipeline dar. Pipelines sind die Grundlage des Add-In-Modells von .NET Framework zum Unterstützen von Aufgaben wie Ermittlung, Aktivierung, Sicherheitsisolation, Ausführungsisolation (unter Verwendung von Anwendungsdomänen und -prozessen), Kommunikation, Verwaltung der Lebensdauer und Versionsverwaltung.

Mit dieser Unterstützung können Entwickler Add-Ins erstellen, die mit den Funktionen einer Hostanwendung integriert werden. In einigen Szenarien müssen Hostanwendungen jedoch von Add-Ins bereitgestellte Benutzeroberflächen anzeigen. Da jede Präsentationstechnologie im .NET Framework über ein eigenes Modell für die Implementierung von Benutzeroberflächen verfügt, unterstützt das .NET Framework-Add-In-Modell keine bestimmte Präsentationstechnologie. Stattdessen erweitert WPF das Add-In-Modell von .NET Framework um Benutzeroberflächenunterstützung für Add-Ins.

WPF-Add-Ins

WPF ermöglicht Ihnen in Verbindung mit dem .NET Framework-Add-In-Modell das Realisieren vieler Szenarien, die Hostanwendungen erfordern, um Benutzeroberflächen von Add-Ins anzuzeigen. Insbesondere gibt es in WPF zwei Programmiermodelle für diese Szenarien:

  1. Das Add-In gibt eine Benutzeroberfläche zurück. Wie im Vertrag definiert, gibt ein Add-In über einen Methodenaufruf eine Benutzeroberfläche an die Hostanwendung zurück. Das Szenario wird in den folgenden Fällen verwendet:

    • Die Darstellung einer vom Add-In zurückgegebenen Benutzeroberfläche hängt von den zur Laufzeit vorhandenen Daten oder Bedingungen ab, z. B. von dynamisch generierten Berichten.

    • Die Benutzeroberfläche für durch ein Add-In bereitgestellte Dienste unterscheidet sich von der Benutzeroberfläche der Hostanwendungen, die das Add-In verwenden können.

    • Das Add-In führt in erster Linie einen Dienst für die Hostanwendung aus und meldet den Status an die Hostanwendung mit einer Benutzeroberfläche.

  2. Das Add-In ist eine Benutzeroberfläche. Ein Add-In ist eine Benutzeroberfläche, wie im Vertrag definiert. Das Szenario wird in den folgenden Fällen verwendet:

    • Ein Add-In stellt ausschließlich die angezeigten Dienste bereit, z. B. eine Werbung.

    • Die Benutzeroberfläche für von einem Add-In bereitgestellte Dienste wird von allen Hostanwendungen genutzt, die das Add-In verwenden können, z. B. Rechner oder Farbauswahl.

In diesen Szenarien ist es erforderlich, dass Benutzeroberflächenobjekte zwischen den Domänen der Hostanwendung und der Add-In-Anwendung übergeben werden können. Da beim Add-In-Modell von .NET Framework für die Kommunikation zwischen Anwendungsdomänen Remoting erforderlich ist, müssen die übergebenen Objekte remotefähig sein.

Ein remotefähiges Objekt stellt die Instanz einer Klasse dar, für die eine oder mehrere der folgenden Aussagen gelten:

Hinweis

Weitere Informationen über das Erstellen von remotefähigen .NET Framework-Objekten finden Sie unter Objekte Remotefähig machen.

Die WPF-Benutzeroberflächentypen sind nicht remotefähig. Um das Problem zu beheben, erweitert WPF das Add-In-Modell von .NET Framework, damit die durch Add-Ins erstellte WPF-Benutzeroberflächen von Hostanwendungen angezeigt werden kann. Diese Unterstützung wird von WPF durch zwei Typen bereitgestellt: die INativeHandleContract-Schnittstelle und zwei statische Methoden, die von der FrameworkElementAdapters-Klasse implementiert werden: ContractToViewAdapter und ViewToContractAdapter. Im Allgemeinen werden diese Typen und Methoden wie folgt verwendet:

  1. WPF erfordert, dass von Add-Ins bereitgestellte Benutzeroberflächen direkt oder indirekt von FrameworkElement abgeleitete Klassen sind, z. B. Formen, Steuerelemente, Benutzersteuerelemente, Layoutbereiche und Seiten.

  2. Wenn in dem Vertrag angegeben ist, dass eine Benutzeroberfläche zwischen dem Add-In und der Hostanwendung übergeben wird, muss er als INativeHandleContract deklariert sein (nicht als FrameworkElement). INativeHandleContract ist eine remotefähige Darstellung der Add-In-, die über Isolationsgrenzen hinweg übergeben werden kann.

  3. Bevor ein FrameworkElement aus der Anwendungsdomäne des Add-Ins übergeben wird, wird es durch Aufrufen von ViewToContractAdapter als INativeHandleContract paketiert.

  4. Nachdem ein INativeHandleContract in die Anwendungsdomäne der Hostanwendung übergeben wurde, muss es durch Aufrufen von ContractToViewAdapter als FrameworkElement erneut paketiert werden.

Wie INativeHandleContract, ContractToViewAdapterund ViewToContractAdapter verwendet werden, hängt vom spezifischen Szenario ab. Die folgenden Abschnitte bieten ausführliche Informationen zu den Programmiermodellen.

Add-In gibt eine Benutzeroberfläche zurück

Damit ein Add-In eine Benutzeroberfläche an eine Hostanwendung zurückgeben kann, müssen folgende Voraussetzungen erfüllt sein:

  1. Hostanwendung, Add-In und Pipeline müssen erstellt worden sein, wie in der .NET Framework-Dokumentation unter Add-Ins und Erweiterbarkeit beschrieben.

  2. Der Vertrag muss IContract implementieren. Zum Zurückgeben einer Benutzeroberfläche muss der Vertrag eine Methode mit einem Rückgabewert vom Typ INativeHandleContract deklarieren.

  3. Die zwischen Add-In und Hostanwendung übergebene Benutzeroberfläche muss direkt oder indirekt von FrameworkElement abgeleitet sein.

  4. Die vom Add-In zurückgegebene Benutzeroberfläche muss von einem FrameworkElement in einen INativeHandleContract umgewandelt werden, bevor sie die Isolationsgrenze überschreitet.

  5. Die zurückgegebene Benutzeroberfläche muss von einem INativeHandleContract in ein FrameworkElement umgewandelt werden, bevor sie die Isolationsgrenze überschreitet.

  6. Die Hostanwendung zeigt das zurückgegebene FrameworkElement an.

Ein Beispiel dafür, wie ein Add-In, das eine Benutzeroberfläche zurückgibt, implementiert wird, finden Sie unter Gewusst wie: Erstellen eines Add-Ins, das eine Benutzeroberfläche zurückgibt.

Add-In ist eine Benutzeroberfläche

Wenn ein Add-In eine Benutzeroberfläche ist, gelten die folgenden Voraussetzungen:

  1. Hostanwendung, Add-In und Pipeline müssen erstellt worden sein, wie in der .NET Framework-Dokumentation unter Add-Ins und Erweiterbarkeit beschrieben.

  2. Die Vertragsschnittstelle für das Add-In muss INativeHandleContract implementieren.

  3. Das an die Hostanwendung übergebene Add-In muss direkt oder indirekt von FrameworkElement abgeleitet sein.

  4. Das Add-In muss von einem FrameworkElement in einen INativeHandleContract umgewandelt werden, bevor es die Isolationsgrenze überschreitet.

  5. Das Add-In muss von einem INativeHandleContract in ein FrameworkElement umgewandelt werden, bevor es die Isolationsgrenze überschreitet.

  6. Die Hostanwendung zeigt das zurückgegebene FrameworkElement an.

Ein Beispiel, in dem das Implementieren eines Add-Ins veranschaulicht wird, bei dem es sich um eine Benutzeroberfläche handelt, finden Sie unter Gewusst wie: Erstellen eines Add-Ins, das eine Benutzeroberfläche ist.

Zurückgeben mehrerer Benutzeroberflächen durch ein Add-In

Add-Ins stellen oft mehrere Benutzeroberflächen zur Verfügung, die von Hostanwendungen angezeigt werden können. Betrachten Sie beispielsweise ein Add-In, das eine Benutzeroberfläche ist, die auch Statusinformationen für die Hostanwendung bereitstellt, ebenfalls als eine Benutzeroberfläche. Sie können ein Add-In dieser Art implementieren, indem Sie eine Kombination der Verfahren aus den Modellen Add-In gibt eine Benutzeroberfläche zurück und Add-In ist eine Benutzeroberfläche verwenden.

Add-Ins und XAML-Browseranwendungen

In den bisherigen Beispielen wurde die Hostanwendung als eigenständige Anwendung installiert. XAML Browseranwendungen (XBAPs, XAML Browser Applications) können jedoch auch Add-Ins hosten, wobei allerdings die folgenden zusätzlichen Erstellungs- und Implementierungsanforderungen gelten:

  • Das XBAP-Anwendungsmanifest muss so konfiguriert sein, dass Pipeline- (Ordner und Assemblys) und Add-In-Assembly in den ClickOnce-Anwendungscache auf dem Clientcomputer heruntergeladen werden, und zwar in denselben Ordner wie XBAP.

  • Der XBAP-Code zum Ermitteln und Laden von Add-Ins muss den ClickOnce-Anwendungscache für die XBAP als Speicherort für Pipeline und Add-In verwenden.

  • Die XBAP muss das Add-In in einen speziellen Sicherheitskontext laden, wenn das Add-In auf lose Dateien verweist, die sich auf der Ursprungssite befinden. Wenn sie von XBAPs gehostet werden, können Add-Ins nur auf lose Dateien verweisen, die auf der Ursprungssite der Hostanwendung gespeichert sind.

In den folgenden Unterabschnitten werden diese Aufgaben ausführlich beschrieben.

Konfigurieren der Pipeline und des Add-Ins für die ClickOnce-Bereitstellung

XBAPs werden in einen sicheren Ordner heruntergeladen und von dort aus im ClickOnce-Bereitstellungscache ausgeführt. Damit eine XBAP ein Add-In hosten kann, müssen auch Pipeline- und Add-In-Assembly in den sicheren Ordner heruntergeladen werden. Um dies zu erreichen, müssen Sie das Anwendungsmanifest so konfigurieren, dass sowohl die Pipeline- als auch die Add-In-Assembly heruntergeladen wird. Diese Aufgabe lässt sich am einfachsten in Visual Studio ausführen, obwohl Pipeline- und Add-In-Assembly im Stammordner des XBAP-Hostprojekts gespeichert sein müssen, damit Visual Studio die Pipelineassemblys ermitteln kann.

Folglich muss der erste Schritt darin bestehen, die Pipeline- und Add-In-Assembly im Stammverzeichnis des XBAP-Projekts zu erstellen. Dazu wird die Buildausgabe der einzelnen Pipelineassembly- und Add-In-Assemblyprojekte festgelegt. Die folgende Tabelle zeigt die Buildausgabepfade für die Pipelineassemblyprojekte und das Add-In-Assemblyprojekt, die sich in demselben Projektmappen- und Stammordner befinden wie das XBAP-Hostprojekt.

Tabelle 1: Buildausgabepfade für die Pipelineassemblys, die von einer XBAP gehostet werden

Pipelineassemblyprojekt Buildausgabepfad
Vertrag ..\HostXBAP\Contracts\
Add-In-Ansicht ..\HostXBAP\AddInViews\
Add-In-seitiger Adapter ..\HostXBAP\AddInSideAdapters\
Hostseitiger Adapter ..\HostXBAP\HostSideAdapters\
Add-In ..\HostXBAP\AddIns\WPFAddIn1

Der nächste Schritt besteht darin, die Pipelineassemblys und die Add-In-Assembly als die Inhaltsdateien der XBAPs in Visual Studio anzugeben. Dazu werden folgende Schritte ausgeführt:

  1. Hinzufügen der Pipeline- und Add-In-Assembly zum Projekt, indem Sie im Projektmappen-Explorer mit der rechten Maustaste auf die einzelnen Pipelineordner klicken und die Option Zu Projekt hinzufügen auswählen.

  2. Festlegen des Buildvorgangs jeder Pipelineassembly und jeder Add-In-Assembly im Eigenschaftenfenster auf Inhalt.

Im letzten Schritt muss das Anwendungsmanifest so konfiguriert werden, dass sowohl die Pipelineassemblydateien als auch die Add-In-Assemblydatei heruntergeladen werden. Die Dateien sollten in Ordnern im Stammverzeichnis des Ordners in dem ClickOnce-Cache gespeichert sein, den die XBAP-Anwendung belegt. Die Konfiguration richten Sie in Visual Studio durch folgende Schritte ein:

  1. Klicken Sie mit der rechten Maustaste auf das XBAP-Projekt, klicken Sie auf Eigenschaften, auf Veröffentlichen und dann auf die Schaltfläche Anwendungsdateien.

  2. Legen Sie im Dialogfeld Anwendungsdateien den Veröffentlichungsstatus der einzelnen Pipeline- und Add-In-DLLs auf Einschließen (Auto) und die Downloadgruppe für die Pipeline- und Add-In-DLLs auf (Erforderlich) fest.

Verwenden der Pipeline und des Add-Ins von der Anwendungsbasis

Sind Pipeline und Add-In für die ClickOnce-Bereitstellung konfiguriert, werden sie in denselben ClickOnce-Cacheordner heruntergeladen wie die XBAP. Damit Pipeline und Add-In von der XBAP verwendet werden können, müssen sie vom XBAP-Code aus der Anwendungsbasis abgerufen werden. Die unterschiedlichen Typen und Member des Add-In-Modells von .NET Framework, die zum Verwenden von Pipelines und Add-Ins verfügbar sind, bieten spezielle Unterstützung für dieses Szenario. Zuerst wird der Pfad durch den ApplicationBase-Enumerationswert identifiziert. Diesen Wert verwenden Sie mit Überladungen der relevanten Add-In-Member, wenn Pipelines verwendet werden sollen, die Folgendes enthalten:

Zugreifen auf die Ursprungssite des Hosts

Damit ein Add-In auf Dateien von der Ursprungssite verweisen kann, muss das Add-In mit einer Sicherheitsisolation geladen werden, die der Hostanwendung entspricht. Diese Sicherheitsebene wird durch den AddInSecurityLevel.Host-Enumerationswert identifiziert und beim Aktivieren eines Add-Ins an die Activate-Methode übergeben.

Architektur des WPF-Add-Ins

Wie wir gesehen haben ermöglicht WPF auf höchster Ebene die Implementierung von Benutzeroberflächen (die direkt oder indirekt von FrameworkElement abgeleitet werden) durch .NET Framework-Add-Ins mithilfe von INativeHandleContract, ViewToContractAdapter und ContractToViewAdapter. Als Ergebnis wird ein FrameworkElement an die Hostanwendung zurückgegeben, das von der Benutzeroberfläche in der Hostanwendung angezeigt wird.

Für einfache Benutzeroberflächen-Add-In-Szenarien reichen diese Informationen für Entwickler aus. Für komplexere Szenarien, insbesondere solche, bei denen weitere WPF-Dienste wie Layout, Ressourcen und Datenbindung zum Einsatz kommen, sind umfassendere Kenntnisse darüber erforderlich, wie WPF das Add-In-Modell von .NET Framework um Unterstützung für Benutzeroberflächen erweitert, um die Vorteile und Einschränkungen zu verstehen.

Im Wesentlichen ist es so, dass WPF keine Benutzeroberfläche von einem Add-In an eine Hostanwendung übergibt, sondern dass WPF das Win32-Fensterhandle für die Benutzeroberfläche übergibt, und zwar unter Verwendung der WPF-Interoperabilität. Daher geschieht Folgendes, wenn eine Benutzeroberfläche von einem Add-In an eine Hostanwendung übergeben wird:

  • Auf der Seite des Add-Ins ruft WPF ein Fensterhandle für die Benutzeroberfläche ab, die von der Hostanwendung angezeigt wird. Das Fensterhandle wird von einer internen WPF-Klasse gekapselt, die von HwndSource abgeleitet wird und INativeHandleContract implementiert. Eine Instanz dieser Klasse wird von ViewToContractAdapter zurückgegeben und von der Anwendungsdomäne des Add-Ins an die Anwendungsdomäne der Hostanwendung gemarshallt.

  • Auf der Seite der Hostanwendung paketiert WPF die HwndSource als interne WPF-Klasse, die von HwndHost abgeleitet ist und INativeHandleContract nutzt. Eine Instanz dieser Klasse wird von ContractToViewAdapter an die Hostanwendung zurückgegeben.

HwndHost dient dazu, Benutzeroberflächen anzuzeigen, die durch Fensterhandles von WPF-Benutzeroberfläche identifiziert werden. Weitere Informationen finden Sie unter Interaktion zwischen WPF und Win32.

Zusammenfassend lässt sich sagen, dass INativeHandleContract, ViewToContractAdapter und ContractToViewAdapter dazu dienen, das Fensterhandle für WPF-Benutzeroberfläche von einem Add-In an eine Hostanwendung zu übergeben, wo es durch HwndHost gekapselt und von der Benutzeroberfläche der Hostanwendung angezeigt wird.

Hinweis

Da die Hostanwendung HwndHost abruft, kann die Hostanwendung das von ContractToViewAdapter zurückgegebene Objekt nicht in den Typ konvertieren, mit dem vom Add-In implementiert wurde (z. B. UserControl).

HwndHost unterliegt naturgemäß bestimmten Einschränkungen bei der Verwendung durch Hostanwendungen. WPF erweitert allerdings HwndHost um mehrere Funktionen für Add-In-Szenarien. Diese Vorteile und die Einschränkungen werden nachstehend beschrieben.

Vorteile des WPF-Add-Ins

Da WPF-Add-In-Benutzeroberflächen von Hostanwendungen mithilfe einer internen Klasse, die von HwndHost abgeleitet wird, angezeigt werden, sind diese Benutzeroberflächen durch die Fähigkeiten von HwndHost eingeschränkt, was Dienste der WPF-Benutzeroberfläche wie Layout, Rendering, Datenbindung, Formate, Vorlagen und Ressourcen betrifft. Allerdings erweitert WPF die interne HwndHost-Unterklasse um zusätzliche Funktionen, darunter:

  • Wechseln mit der TAB-Taste zwischen der Benutzeroberfläche einer Hostanwendung und der Benutzeroberfläche eines Add-Ins. Beachten Sie, dass es für das Programmiermodell „Add-In ist eine Benutzeroberfläche“ erforderlich ist, dass der Add-In-seitige Adapter QueryContract überschreibt, um das Wechseln mit der TAB-TASTE zu aktivieren. Dies gilt sowohl für voll vertrauenswürdige als auch für teilweise vertrauenswürdige Add-Ins.

  • Anforderungsgemäße Barrierefreiheit für Add-In-Benutzeroberflächen, die von Hostanwendungs-Benutzeroberflächen angezeigt werden.

  • Sichere Ausführung von WPF-Anwendungen in Szenarien mit mehreren Anwendungsdomänen.

  • Verhindern von unberechtigten Zugriffen auf Fensterhandles von Add-In-Benutzeroberflächen, wenn Add-Ins mit Sicherheitsisolation ausgeführt werden (d. h. in einem teilweise vertrauenswürdigen Sicherheitsbereich (Sandbox)). Das Aufrufen von ViewToContractAdapter stellt diese Sicherheit her:

    • Beim Programmiermodell „Add-In gibt eine Benutzeroberfläche zurück“, kann nur dadurch das Fensterhandle für die Benutzeroberfläche eines Add-Ins über die Isolationsgrenze hinweg übergeben werden, dass ViewToContractAdapter aufgerufen wird.

    • Beim Programmiermodell „Add-In ist eine Benutzeroberfläche“ ist es erforderlich, QueryContract auf dem Add-In-seitigen Adapter zu überschreiben und ViewToContractAdapter aufzurufen (wie in den vorhergehenden Beispielen gezeigt). Außerdem muss die QueryContract-Implementierung des Add-In-Adapters vom hostseitigen Adapter aufgerufen werden.

  • Bereitstellen von Ausführungsschutz für mehrere Anwendungsdomänen. Aufgrund von Einschränkungen bei Anwendungsdomänen führen unbehandelte Ausnahmen, die in Add-In-Anwendungsdomänen ausgelöst werden, zum Absturz der gesamten Anwendung, auch wenn eine Isolationsgrenze eingerichtet ist. WPF und das Add-In-Modell von .NET Framework bieten jedoch eine einfache Möglichkeit, das Problem zu umgehen und die Anwendungsstabilität zu verbessern. Ein WPF-Add-In, das eine Benutzeroberfläche anzeigt, erstellt einen Dispatcher für den Thread, auf dem die Anwendungsdomäne ausgeführt wird, wenn die Hostanwendung eine WPF-Anwendung ist. Sie können alle unbehandelten Ausnahmen ermitteln, die in der Anwendungsdomäne auftreten, indem Sie das UnhandledException-Ereignis vom Dispatcher des WPF-Add-Ins behandeln. Sie können den Dispatcher aus der CurrentDispatcher-Eigenschaft abrufen.

Einschränkungen des WPF-Add-Ins

Neben den Vorteilen, die WPF für die von HwndSource, HwndHost und Fensterhandles bereitgestellten Standardverhalten bietet, gibt es auch Einschränkungen für Add-Ins, die von Hostanwendungen angezeigt werden:

  • Das Ausschneideverhalten der Hostanwendung wird von den von einer Hostanwendung angezeigten Add-In-Benutzeroberflächen nicht berücksichtigt.

  • Der Begriff Airspace in Interoperabilitätsszenarien gilt auch für Add-Ins (siehe Übersicht über die Technologieregionen).

  • Die Benutzeroberflächendienste einer Hostanwendung, z. B. Ressourcenvererbung, Datenbindung und Befehle sind für Add-In-Benutzeroberflächen nicht automatisch verfügbar. Um diese Dienste für das Add-In bereitzustellen, müssen Sie die Pipeline aktualisieren.

  • Die Benutzeroberfläche eines Add-Ins kann nicht gedreht, skaliert, geschert oder auf andere Weise durch eine Transformation geändert werden (siehe Übersicht über Transformationen).

  • Inhalte innerhalb von Add-In-Benutzeroberflächen, die durch Zeichenvorgänge aus dem System.Drawing-Namespace gerendert werden, können Alphablending umfassen. Allerdings müssen sowohl die Benutzeroberfläche eines Add-Ins als auch die sie enthaltende Benutzeroberfläche der Hostanwendung zu 100 % deckend sein, d. h., die Opacity-Eigenschaft muss für beide auf 1 festgelegt sein.

  • Wenn die AllowsTransparency-Eigenschaft eines Fensters in der Hostanwendung, die die Benutzeroberfläche eines Add-Ins enthält, auf true festgelegt ist, ist das Add-In nicht sichtbar. Dies gilt auch, wenn die Benutzeroberfläche des Add-Ins zu 100 % deckend ist (die Opacity-Eigenschaft also den Wert 1 hat).

  • Die Benutzeroberfläche des Add-Ins muss über anderen WPF-Elementen in demselben Fenster auf oberster Ebene angezeigt werden.

  • Kein Teil einer Add-In-Benutzeroberfläche kann mit einem VisualBrush gerendert werden. Stattdessen kann das Add-In eine Momentaufnahme der generierten Benutzeroberfläche erstellen, um eine Bitmap zu erstellen, die mit vertraglich definierten Methoden an die Hostanwendung übergeben werden kann.

  • Mediendateien können nicht von einem MediaElement in der Benutzeroberfläche eines Add-Ins wiedergegeben werden.

  • Für die Add-In-Benutzeroberfläche generierte Mausereignisse werden von der Hostanwendung weder empfangen noch ausgelöst. Die IsMouseOver-Eigenschaft für die Benutzeroberfläche der Hostanwendung hat den Wert false.

  • Wenn der Fokus zwischen Steuerelementen in einer Add-In-Benutzeroberfläche wechselt, werden die Ereignisse GotFocus und LostFocus von der Hostanwendung weder empfangen noch ausgelöst.

  • Der Teil einer Hostanwendung, der eine Add-In-Benutzeroberfläche enthält, wird beim Drucken weiß angezeigt.

  • Alle Dispatcher (siehe Dispatcher), die von der Add-In-Benutzeroberfläche erstellt wurden, müssen manuell beendet werden, bevor das Add-In des Besitzers entladen wird, wenn die Hostanwendung weiterhin ausgeführt wird. Der Vertrag kann Methoden implementieren, die es der Hostanwendung ermöglichen, dem Add-In vor dem Entladen ein Signal zu übermitteln. Dadurch kann die Add-In-Benutzeroberfläche die Dispatcher beenden.

  • Handelt es sich bei der Add-In-Benutzeroberfläche um InkCanvas, oder enthält sie InkCanvas, können Sie das Add-In nicht entladen.

Leistungsoptimierung

Werden mehrere Anwendungsdomänen verwendet, werden die von den einzelnen Anwendungen benötigten verschiedenen .NET Framework-Assemblys standardmäßig alle in die Domäne dieser Anwendung geladen. Aufgrund der Zeit, die zum Erstellen neuer Anwendungsdomänen und für das Starten der darin enthaltenen Anwendungen erforderlich ist, kann die Leistung beeinträchtigt werden. .NET Framework bietet allerdings die Möglichkeit, Startzeiten zu verkürzen. Dazu werden Anwendungen angewiesen, Assemblys in Anwendungsdomänen gemeinsam zu nutzen, wenn sie bereits geladen sind. Um dies zu erreichen, verwenden Sie das LoaderOptimizationAttribute-Attribut, das auf die Einstiegspunktmethode (Main) angewendet werden muss. In diesem Fall müssen Sie lediglich zum Implementieren Ihrer Anwendungsdefinition Code verwenden (siehe Übersicht über die Anwendungsverwaltung).

Weitere Informationen