Übersicht über WPF-Add-Ins
.NET Framework beinhaltet 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 UIs anzeigen, die von Add-Ins bereitgestellt werden. In diesem Thema wird gezeigt, wie durch WPF das Add-In-Modell von .NET Framework erweitert wird, um diese Szenarien sowie die zugrunde liegende Architektur, die Vorteile und die Einschränkungen zu ermöglichen.
Dieses Thema enthält folgende Abschnitte.
- Erforderliche Komponenten
- Übersicht über Add-Ins
- Übersicht über das Add-In-Modell von .NET Framework
- WPF-Add-Ins
- Add-In gibt eine Benutzeroberfläche zurück
- Add-In ist eine Benutzeroberfläche
- Zurückgeben mehrerer Benutzeroberflächen durch ein Add-In
- Add-Ins und XAML-Browseranwendungen
- Architektur des WPF-Add-Ins
- Vorteile des WPF-Add-Ins
- Einschränkungen des WPF-Add-Ins
- Leistungsoptimierung
- Verwandte Abschnitte
Erforderliche Komponenten
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 .NET Framework eine Infrastruktur zum Erstellen von Add-In-Modellen bereit.
.gif "Hinweis") 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 Fundament 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, wenn es für das Add-In-Modell von .NET Framework darum geht, Aufgaben wie Ermittlung, Aktivierung, Sicherheitsisolation, Ausführungsisolation (unter Verwendung von Anwendungsdomänen und -prozessen), Kommunikation, Verwaltung der Lebensdauer und Versionsverwaltung zu unterstützen.
Mit dieser Unterstützung können Entwickler Add-Ins erstellen, die mit den Funktionen einer Hostanwendung integriert werden. In einigen Szenarien müssen Hostanwendungen die von Add-Ins bereitgestellten UIs anzeigen. Da jede Präsentationstechnologie in .NET Framework über ein eigenes Modell zum Implementieren von UIs verfügt, unterstützt das Add-In-Modell von .NET Framework keine bestimmte Präsentationstechnologie. Stattdessen erweitert WPF das Add-In-Modell von .NET Framework um UInunterstützung für Add-Ins.
WPF-Add-Ins
Wenn Sie WPF in Verbindung mit dem Add-In-Modell von .NET Framework verwenden, können Sie den unterschiedlichsten Szenarien gerecht werden, in denen Hostanwendungen UIs aus Add-Ins anzeigen müssen. Für diese Szenarien eignet sich insbesondere WPF mit den folgenden zwei Programmiermodellen:
Das Add-In gibt eine Benutzeroberfläche zurück. Wie im Vertrag definiert, gibt ein Add-In über einen Methodenaufruf eine UI an die Hostanwendung zurück. Das Szenario wird in den folgenden Fällen verwendet:
Die Darstellung einer vom Add-In zurückgegebenen UI hängt von den zur Laufzeit vorhandenen Daten oder Bedingungen ab, z. B. von dynamisch generierten Berichten.
Die UI für durch ein Add-In bereitgestellte Dienste unterscheidet sich von der UI 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 UI.
Das Add-In ist eine Benutzeroberfläche. Ein Add-In ist eine UI, 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 UI 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 UInobjekte 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:
Wird von der MarshalByRefObject-Klasse abgeleitet.
Implementiert die ISerializable-Schnittstelle.
Verfügt über das SerializableAttribute-Attribut.
| Hinweis |
|---|
Weitere Informationen über das Erstellen von remotefähigen .NET Framework-Objekten finden Sie unter Making Objects Remotable. |
Die UIntypen von WPF 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-UI von Hostanwendungen angezeigt werden kann. Diese Unterstützung stellt WPF durch zwei Typen bereit: 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:
WPF erfordert, dass von Add-Ins bereitgestellte UIs direkt oder indirekt von FrameworkElement abgeleitete Klassen sind, z. B. Formen, Steuerelemente, Benutzersteuerelemente, Layoutbereiche und Seiten.
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-UI, die über Isolationsgrenzen hinweg übergeben werden kann.
Vor dem Übergeben von der Anwendungsdomäne des Add-Ins wird ein FrameworkElement als INativeHandleContract gepackt. Dies geschieht durch Aufrufen von ViewToContractAdapter.
Nach dem Übergeben an die Anwendungsdomäne der Hostanwendung muss der INativeHandleContract erneut als FrameworkElement gepackt werden. Die geschieht durch Aufrufen von ContractToViewAdapter.
Die Verwendung von INativeHandleContract, ContractToViewAdapter und ViewToContractAdapter hängt von dem jeweiligen 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 UI an eine Hostanwendung zurückgeben kann, müssen folgende Voraussetzungen erfüllt sein:
Hostanwendung, Add-In und Pipeline müssen erstellt worden sein, wie in der .NET Framework-Dokumentation unter Add-Ins und Erweiterbarkeit beschrieben.
Der Vertrag muss IContract implementieren. Zum Zurückgeben einer UI muss der Vertrag eine Methode mit einem Rückgabewert vom Typ INativeHandleContract deklarieren.
Die zwischen Add-In und Hostanwendung übergebene UI muss direkt oder indirekt von FrameworkElement abgeleitet werden.
Die vom Add-In zurückgegebene UI muss vor dem Überschreiten der Isolationsgrenze von FrameworkElement in INativeHandleContract umgewandelt werden.
Die zurückgegebene UI muss nach dem Überschreiten der Isolationsgrenze von INativeHandleContract in FrameworkElement umgewandelt werden.
Die Hostanwendung zeigt das zurückgegebene FrameworkElement an.
Ein Beispiel dafür, wie ein Add-In, das eine UI 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 UI ist, gelten die folgenden Voraussetzungen:
Hostanwendung, Add-In und Pipeline müssen erstellt worden sein, wie in der .NET Framework-Dokumentation unter Add-Ins und Erweiterbarkeit beschrieben.
Die Vertragsschnittstelle für das Add-In muss INativeHandleContract implementieren.
Das an die Hostanwendung übergebene Add-In muss direkt oder indirekt von FrameworkElement abgeleitet werden.
Das Add-In muss vor dem Überschreiten der Isolationsgrenze von FrameworkElement in INativeHandleContract umgewandelt werden.
Das Add-In muss nach dem Überschreiten der Isolationsgrenze von INativeHandleContract in FrameworkElement umgewandelt werden.
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 UI 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 UIs zur Verfügung, die Hostanwendungen anzeigen können. Betrachten Sie beispielsweise ein Add-In, das eine UI ist, die auch Statusinformationen für die Hostanwendung bereitstellt, gleichzeitig als eine UI. 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 browser applications (XBAPs) 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 XBAP als Speicherort für Pipeline und Add-In verwenden.
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 |
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:
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.
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:
Klicken Sie mit der rechten Maustaste auf das XBAP-Projekt, klicken Sie auf Eigenschaften, auf Veröffentlichen und dann auf die Schaltfläche Anwendungsdateien.
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 aus 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 bereits erwähnt, ermöglicht WPF auf oberster Ebene, dass .NET Framework-Add-Ins UIs implementieren (die direkt oder indirekt von FrameworkElement abgeleitet werden), und zwar mithilfe von INativeHandleContract, ViewToContractAdapter und ContractToViewAdapter. Als Ergebnis wird an die Hostanwendung FrameworkElement zurückgegeben, das von der UI in der Hostanwendung angezeigt wird.
Für einfache UIn-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 UInunterstützung erweitert. Andernfalls können Sie die Vorteile und Einschränkungen nicht verstehen.
Im Wesentlichen ist es so, dass WPF keine UI von einem Add-In an eine Hostanwendung übergibt, sondern dass WPF das Win32-Fensterhandle für die UI übergibt, und zwar unter Verwendung der WPF-Interoperabilität. Daher geschieht Folgendes, wenn eine UI von einem Add-In an eine Hostanwendung übergeben wird:
Auf der Seite des Add-Ins ruft WPF ein Fensterhandle für die UI 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 wird HwndSource von WPF als interne WPF-Klasse neu gepackt, die von HwndHost abgeleitet wird und INativeHandleContract nutzt. Eine Instanz dieser Klasse wird von ContractToViewAdapter an die Hostanwendung zurückgegeben.
HwndHost ist enthalten, damit die durch Fensterhandles identifizierten UIs aus WPF-UIs angezeigt werden. Weitere Informationen finden Sie unter Interaktion zwischen WPF und Win32.
Zusammenfassend lässt sich sagen, dass INativeHandleContract, ViewToContractAdapter und ContractToViewAdapter vorhanden sind, damit das Fensterhandle für eine WPF-UI von einem Add-In an eine Hostanwendung übergeben werden kann, wo es durch HwndHost gekapselt und von der UI 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 bestimmten Einschränkungen, die sich auf die Verwendung durch Hostanwendungen auswirken. WPF erweitert HwndHost allerdings um mehrere Funktionen für Add-In-Szenarien. Diese Vorteile und die Einschränkungen werden nachstehend beschrieben.
Vorteile des WPF-Add-Ins
Da Add-In-UIs von WPF mithilfe einer internen Klasse, die von HwndHost abgeleitet wird, über Hostanwendungen angezeigt werden, sind diese UIs durch die Funktionen von HwndHost eingeschränkt, was Dienste der UI von WPF wie Layout, Rendering, Datenbindung, Formate, Vorlagen und Ressourcen betrifft. Allerdings erweitert WPF die interne HwndHost-Unterklasse um zusätzliche Funktionen, beispielsweise:
Wechseln mit der TAB-TASTE zwischen der UI einer Hostanwendung und der UI eines Add-Ins. Beachten Sie, dass es für das Programmiermodell "Add-In ist eine UI" 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.
Berücksichtigen der Anforderungen an Barrierefreiheit für Add-In-UIs, die von UIs für Hostanwendungen angezeigt werden.
Ermöglichen, dass WPF-Anwendungen in Szenarien mit mehreren Anwendungsdomänen sicher ausgeführt werden.
Verhindern von unberechtigten Zugriffen auf Add-In-UIn-Fensterhandles, wenn Add-Ins mit Sicherheitsisolation ausgeführt werden (d. h. in einem teilweise vertrauenswürdigen Sicherheitsbereich (Sandbox)). Das Aufrufen von ViewToContractAdapter gewährleistet diese Sicherheit:
Beim Programmiermodell "Add-In gibt eine UI zurück", kann nur dadurch das Fensterhandle für die UI eines Add-Ins über die Isolationsgrenze hinweg übergeben werden, dass ViewToContractAdapter aufgerufen wird.
Beim Programmiermodell "Add-In ist eine UI" 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-seitigen 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 UI anzeigt, erstellt 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 ermitteln, die in der Anwendungsdomäne auftreten, indem Sie das UnhandledException-Ereignis von Dispatcher des WPF-Add-Ins behandeln. Sie können 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-In-UIs, die von Hostanwendungen angezeigt werden:
Das Ausschneideverhalten der Hostanwendung wird von den von einer Hostanwendung angezeigten Add-In-UIs nicht berücksichtigt.
Der Begriff Airspace in Interoperabilitätsszenarien gilt auch für Add-Ins (siehe Übersicht über die Technologieregionen).
Die UIndienste einer Hostanwendung, z. B. Ressourcenvererbung, Datenbindung und Befehle sind für Add-In-UIs nicht automatisch verfügbar. Um diese Dienste für das Add-In bereitzustellen, müssen Sie die Pipeline aktualisieren.
Die UI eines Add-Ins kann nicht gedreht, skaliert, verzerrt oder auf andere Weise durch eine Transformation geändert werden (siehe Übersicht über Transformationen).
Inhalte innerhalb von Add-In-UIs, die durch Zeichenvorgänge aus dem System.Drawing-Namespace gerendert werden, können Alphablending umfassen. Allerdings müssen sowohl die UI eines Add-Ins als auch die sie enthaltende UI 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 UI eines Add-Ins enthält, auf true festgelegt ist, ist das Add-In nicht sichtbar. Dies gilt auch, wenn die UI des Add-Ins zu 100 % deckend ist (die Opacity-Eigenschaft also den Wert 1 hat).
Die UI eines Add-Ins muss über anderen WPF-Elementen in demselben Fenster auf oberster Ebene angezeigt werden.
Kein Teil einer Add-In-UI kann mit VisualBrush gerendert werden. Stattdessen kann das Add-In eine Momentaufnahme der generierten UI 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 UI eines Add-Ins wiedergegeben werden.
Für die Add-In-UI generierte Mausereignisse werden von der Hostanwendung weder empfangen noch ausgelöst. Die IsMouseOver-Eigenschaft für die UI der Hostanwendung hat den Wert false.
Wenn der Fokus zwischen Steuerelementen in einer Add-In-UI wechselt, wird das GotFocus-Ereignis und das LostFocus-Ereignis von der Hostanwendung weder empfangen noch ausgelöst.
Der Teil einer Hostanwendung, der eine Add-In-UI enthält, wird beim Drucken weiß angezeigt.
Alle Dispatcher (siehe Dispatcher), die von der Add-In-UI erstellt wurden, müssen manuell beendet werden, bevor das Add-In des Besitzers entladen wird, wenn die Ausführung der Hostanwendung fortgesetzt 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-UI die Dispatcher beenden.
Handelt es sich bei der Add-In-UI 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).