Freigeben über

Übersicht über WPF-Add-Ins

  • Artikel

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

Voraussetzungen

Vertrautheit mit dem .NET Framework-Add-In-Modell ist erforderlich. Weitere Informationen finden Sie unter Add-Ins und Erweiterbarkeit.

Übersicht über Add-Ins

Um die Komplexität der Anwendungsneukompilierung und erneute Bereitstellung zu vermeiden, um neue Funktionen zu integrieren, implementieren Anwendungen Erweiterbarkeitsmechanismen, mit denen Entwickler (sowohl Erstanbieter als auch Drittanbieter) andere Anwendungen erstellen können, die in diese integriert sind. Die am häufigsten verwendete Möglichkeit zur Unterstützung dieser Art von Erweiterbarkeit besteht in der Verwendung von Add-Ins (auch als "Add-Ons" und "Plug-Ins" bezeichnet). Beispiele für reale Anwendungen, die erweiterbarkeit mit Add-Ins verfügbar machen, sind:

  • Internet Explorer-Erweiterungen.

  • Windows Media Player-Plug-Ins.

  • Visual Studio-Erweiterungen.

Mit dem Windows Media Player-Add-In-Modell können Entwickler von Drittanbietern beispielsweise "Plug-Ins" implementieren, die Windows Media Player auf vielfältige Weise erweitern, einschließlich der Erstellung von Decodern und Encodern für Medienformate, die von Windows Media Player (z. B. DVD, MP3), Audioeffekten und Skins nicht nativ unterstützt werden. Jedes Add-In-Modell ist so aufgebaut, dass die Funktionalität verfügbar gemacht wird, die für eine Anwendung eindeutig ist, obwohl es mehrere Entitäten und Verhaltensweisen gibt, die allen Add-In-Modellen gemeinsam sind.

Die drei Hauptentitäten typischer Add-In-Erweiterbarkeitslösungen sind Verträge, Add-Ins und Hostanwendungen. Verträge definieren die Integration von Add-Ins in Hostanwendungen auf zwei Arten:

  • 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 haben Anwendungen, die Add-Ins unterstützen, die folgenden zusätzlichen Zuständigkeiten:

  • 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: Zulassen, dass Add-Ins und Hostanwendungen über Isolationsgrenzen hinweg miteinander kommunizieren können, indem Methoden aufgerufen und Daten übergeben werden.

  • Lifetime Management: Laden und Entladen von Anwendungsdomänen und -prozessen auf saubere, vorhersehbare Weise (siehe Anwendungsdomänen).

  • Versionsverwaltung: Sicherstellen, dass Hostanwendungen und Add-Ins weiterhin kommunizieren können, wenn neue Versionen von beiden erstellt werden.

Letztendlich ist die Entwicklung eines robusten Add-In-Modells ein nicht triviales Unternehmen. Aus diesem Grund stellt .NET Framework eine Infrastruktur zum Erstellen von Add-In-Modellen bereit.

Anmerkung

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

.NET Framework Add-In Modellübersicht

Das .NET Framework-Add-In-Modell im System.AddIn-Namespace enthält eine Reihe von Typen, die die Entwicklung der Add-In-Erweiterbarkeit vereinfachen sollen. Die grundlegende Einheit des .NET Framework-Add-In-Modells ist der Vertrag, der definiert, 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, auf der das .NET Framework-Add-In-Modell Ermittlung, Aktivierung, Sicherheitsisolation, Ausführungsisolation (sowohl unter Verwendung von Anwendungsdomänen als auch Prozessen), Kommunikation, Lebensdauerverwaltung und Versionsverwaltung unterstützt.

Die Summe dieser Unterstützung ermöglicht Entwicklern das Erstellen von Add-Ins, die in die Funktionalität einer Hostanwendung integriert werden. Einige Szenarien erfordern jedoch Hostanwendungen zum Anzeigen von Benutzeroberflächen, die von Add-Ins bereitgestellt werden. Da jede Präsentationstechnologie in .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

Mit WPF können Sie in Verbindung mit dem .NET Framework-Add-In-Modell eine Vielzahl von Szenarien behandeln, in denen Hostanwendungen benutzeroberflächen von Add-Ins anzeigen müssen. Insbesondere werden diese Szenarien von WPF mit den folgenden beiden Programmiermodellen behandelt:

  1. Das Add-In gibt eine Benutzeroberfläche zurück. Ein Add-In gibt eine Benutzeroberfläche über einen Methodenaufruf an die Hostanwendung zurück, wie durch den Vertrag definiert. Dieses 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 Dienste, die von einem Add-In bereitgestellt werden, 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 der Hostanwendung mit einer Benutzeroberfläche.

  2. Das Add-In ist eine Benutzeroberfläche. Ein Add-In ist eine Benutzeroberfläche, wie durch den Vertrag definiert. Dieses 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 Dienste, die von einem Add-In bereitgestellt werden, ist einheitlich für alle Hostanwendungen, die dieses Add-In verwenden können, z. B. einen Rechner oder eine Farbauswahl.

Diese Szenarien erfordern, dass UI-Objekte zwischen Hostanwendungs- und Add-In-Anwendungsdomänen übergeben werden können. Da das .NET Framework-Add-In-Modell auf Remoting angewiesen ist, um zwischen Anwendungsdomänen zu kommunizieren, müssen die zwischen ihnen übergebenen Objekte remotable sein.

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

Anmerkung

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

Die WPF-UI-Typen sind nicht remotable. Um das Problem zu lösen, erweitert WPF das .NET Framework-Add-In-Modell, sodass von Add-Ins erstellte WPF-Benutzeroberflächen in Hostanwendungen angezeigt werden können. 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. Auf hoher Ebene werden diese Typen und Methoden auf folgende Weise 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 der Vertrag deklariert, dass eine Benutzeroberfläche zwischen dem Add-In und der Hostanwendung übergeben wird, muss sie als INativeHandleContract deklariert werden (nicht als FrameworkElement); INativeHandleContract ist eine remotable Darstellung der Add-In-Benutzeroberfläche, 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 jeweiligen Szenario ab. Die folgenden Abschnitte enthalten Details für jedes Programmiermodell.

Add-In gibt eine Benutzeroberfläche zurück.

Damit ein Add-In eine Benutzeroberfläche an eine Hostanwendung zurückgibt, ist Folgendes erforderlich:

  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 und zum Zurückgeben einer Benutzeroberfläche muss der Vertrag eine Methode mit einem Rückgabewert vom Typ INativeHandleContractdeklarieren.

  3. Die Benutzeroberfläche, die zwischen dem Add-In und der Hostanwendung übergeben wird, muss direkt oder indirekt von FrameworkElementabgeleitet werden.

  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 Erstellen eines Add-Ins, das eine Benutzeroberfläche zurückgibt.

Add-In ist eine Benutzeroberfläche

Wenn ein Add-In eine Benutzeroberfläche ist, ist Folgendes erforderlich:

  1. Die Hostanwendung, das Add-In und die Pipeline müssen erstellt werden, wie es in der Dokumentation zur Add-In- und Erweiterbarkeit des .NET Frameworks beschrieben wird.

  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 häufig mehrere Benutzeroberflächen bereit, über die 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 war die Hostanwendung eine eigenständig installierte Anwendung. Xaml-Browseranwendungen (XBAPs) können jedoch auch Add-Ins hosten, wenn auch mit den folgenden zusätzlichen Build- und Implementierungsanforderungen:

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

Diese Aufgaben werden in den folgenden Unterabschnitten 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

Pipeline-Montageprojekt Ausgabepfad erstellen
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 kann in Visual Studio wie folgt erreicht werden:

  1. Klicken Sie mit der rechten Maustaste auf das XBAP-Projekt, klicken Sie auf Eigenschaften, klicken Sie auf Veröffentlichen, und klicken Sie 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 Ursprungswebsite des Hosts

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

WPF-Add-In-Architektur

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 Add-In-Szenarien für Benutzeroberflächen ist dies der Grad an Detailgenauigkeit, den ein Entwickler benötigt. Für komplexere Szenarien, insbesondere für solche, die zusätzliche WPF-Dienste wie Layout, Ressourcen und Datenbindung nutzen möchten, sind ausführlichere Kenntnisse darüber, wie WPF das .NET Framework-Add-In-Modell mit UI-Unterstützung erweitert, erforderlich, um seine 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. Wenn eine Benutzeroberfläche eines Add-Ins an eine Hostanwendung übergeben wird, geschieht Folgendes:

  • 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 in die Domäne der Hostanwendung übertragen.

  • 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ächen identifiziert werden. Weitere Informationen finden Sie unter WPF- und Win32-Interoperabilität.

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

Anmerkung

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 hat in seiner Natur bestimmte Einschränkungen, die sich darauf auswirken, wie Hostanwendungen sie verwenden können. WPF erweitert allerdings HwndHost um mehrere Funktionen für Add-In-Szenarien. Diese Vorteile und Einschränkungen werden unten beschrieben.

Vorteile des WPF-Add-Ins

Da WPF-Add-In-Benutzeroberflächen von Hostanwendungen mithilfe einer internen Klasse angezeigt werden, die von HwndHostabgeleitet wird, werden diese Benutzeroberflächen durch die Funktionen von HwndHost in Bezug auf WPF-UI-Dienste wie Layout, Rendering, Datenbindung, Stile, Vorlagen und Ressourcen eingeschränkt. WPF erweitert jedoch seine interne HwndHost-Unterklasse mit zusätzlichen Funktionen, die Folgendes enthalten:

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

  • Aktivieren der sicheren Ausführung von WPF-Anwendungen in mehreren Anwendungsdomänenszenarien.

  • 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 sicher:

    • 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, indem 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.

  • Bereitstellung 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, dazu, dass die gesamte Anwendung abstürzt, obwohl die Isolationsgrenze vorhanden ist. WPF und das .NET Framework-Add-In-Modell bieten jedoch eine einfache Möglichkeit, dieses Problem zu umgehen und die Anwendungsstabilität zu verbessern. Ein WPF-Add-In, das eine Benutzeroberfläche anzeigt, erstellt eine Dispatcher für den Thread, auf dem die Anwendungsdomäne ausgeführt wird, wenn es sich bei der Hostanwendung um eine WPF-Anwendung handelt. Sie können alle unbehandelten Ausnahmen, die in der Anwendungsdomäne auftreten, erkennen, indem Sie das Ereignis UnhandledException des WPF-Add-Ins Dispatcherbehandeln. 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 UI-Dienste 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.

  • Eine Add-In-Benutzeroberfläche kann nicht gedreht, skaliert, verzerrt oder anderweitig durch eine Transformation beeinflusst werden (siehe Transformationsübersicht).

  • 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 eine Benutzeroberfläche für Add-Ins enthält, auf truefestgelegt ist, ist das Add-In unsichtbar. 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 daraus eine Bitmap zu erstellen, die mithilfe von Methoden, die durch die Vertragsvereinbarung definiert sind, 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

Wenn mehrere Anwendungsdomänen verwendet werden, werden standardmäßig die verschiedenen .NET Framework-Assemblys, die für jede Anwendung erforderlich sind, in die Domäne dieser Anwendung geladen. Daher kann sich die erforderliche Zeit für das Erstellen neuer Anwendungsdomänen und das Starten von Anwendungen auf die Leistung auswirken. Das .NET Framework bietet jedoch eine Möglichkeit, die Startzeiten zu reduzieren, indem Anwendungen angewiesen werden, Assemblys über Anwendungsdomänen hinweg freizugeben, 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 nur Code verwenden, um Ihre Anwendungsdefinition zu implementieren (siehe Anwendungsverwaltungsübersicht).

Siehe auch