Delen via

Overzicht van WPF-Add-Ins

Het .NET Framework bevat een invoegtoepassingsmodel dat ontwikkelaars kunnen gebruiken om toepassingen te maken die uitbreiding van invoegtoepassingen ondersteunen. Met dit invoegtoepassingsmodel kunt u invoegtoepassingen maken die kunnen worden geïntegreerd met de functionaliteit van toepassingen en deze uitbreiden. In sommige scenario's moeten toepassingen ook gebruikersinterfaces weergeven die worden geleverd door invoegtoepassingen. In dit onderwerp wordt beschreven hoe WPF het .NET Framework-invoegtoepassingsmodel vergroot om deze scenario's, de architectuur erachter, de voordelen en de beperkingen ervan mogelijk te maken.

Vereiste voorwaarden

Bekendheid met het .NET Framework-invoegtoepassingsmodel is vereist. Zie invoegtoepassingen en uitbreidbaarheidvoor meer informatie.

overzicht van Add-Ins

Om de complexiteit van de hercompilatie en herimplementatie van toepassingen te voorkomen om nieuwe functionaliteit op te nemen, implementeren toepassingen uitbreidbaarheidsmechanismen waarmee ontwikkelaars (zowel van de eerste partij als van derden) andere toepassingen kunnen maken die ermee worden geïntegreerd. De meest voorkomende manier om dit type uitbreidbaarheid te ondersteunen, is door gebruik te maken van invoegtoepassingen (ook wel 'add-ons' en 'plug-ins' genoemd). Voorbeelden van echte toepassingen die uitbreidbaarheid met invoegtoepassingen beschikbaar maken, zijn:

  • Internet Explorer-invoegtoepassingen.

  • Windows Media Player-invoegtoepassingen.

  • Visual Studio-invoegtoepassingen.

Met het Windows Media Player-invoegtoepassingsmodel kunnen externe ontwikkelaars bijvoorbeeld 'plug-ins' implementeren die Windows Media Player op verschillende manieren uitbreiden, waaronder het maken van decoders en encoders voor media-indelingen die niet systeemeigen worden ondersteund door Windows Media Player (bijvoorbeeld DVD, MP3), audio-effecten en skins. Elk invoegtoepassingsmodel is gebouwd om de functionaliteit beschikbaar te maken die uniek is voor een toepassing, hoewel er verschillende entiteiten en gedragingen zijn die gebruikelijk zijn voor alle invoegtoepassingsmodellen.

De drie belangrijkste entiteiten van typische uitbreidbaarheidsoplossingen voor invoegtoepassingen zijn contracten, invoegtoepassingenen hosttoepassingen. Contracten bepalen hoe invoegtoepassingen op twee manieren kunnen worden geïntegreerd met hosttoepassingen:

  • Invoegtoepassingen kunnen worden geïntegreerd met functionaliteit die wordt geïmplementeerd door hosttoepassingen.

  • Hosttoepassingen bieden functionaliteit voor invoegtoepassingen om mee te integreren.

Om invoegtoepassingen te kunnen gebruiken, moeten hosttoepassingen ze vinden en laden tijdens runtime. Daarom hebben toepassingen die ondersteuning bieden voor invoegtoepassingen de volgende extra verantwoordelijkheden:

  • Ontdekking-: Zoeken naar invoegtoepassingen die aan contracten voldoen die ondersteund worden door hosttoepassingen.

  • Activering: Laden, uitvoeren en tot stand brengen van communicatie met invoegtoepassingen.

  • Isolatie: toepassingsdomeinen of -processen gebruiken om isolatiegrenzen vast te stellen die toepassingen beschermen tegen mogelijke beveiligings- en uitvoeringsproblemen met invoegtoepassingen.

  • Communication: invoegtoepassingen en hosttoepassingen toestaan om met elkaar te communiceren over isolatiegrenzen door methoden aan te roepen en gegevens door te geven.

  • Levensduurbeheer: toepassingsdomeinen en -processen laden en lossen op een schone, voorspelbare manier (zie Toepassingsdomeinen).

  • versiebeheer: ervoor zorgen dat hosttoepassingen en invoegtoepassingen nog steeds kunnen communiceren wanneer er nieuwe versies van beide worden gemaakt.

Uiteindelijk is het ontwikkelen van een robuust invoegtoepassingsmodel een niet-triviale onderneming. Daarom biedt .NET Framework een infrastructuur voor het bouwen van invoegtoepassingsmodellen.

Opmerking

Zie Invoegtoepassingen en uitbreidbaarheidvoor meer gedetailleerde informatie over invoegtoepassingen.

Overzicht van .NET Framework Add-In-model

Het .NET Framework-invoegtoepassingsmodel in de System.AddIn naamruimte bevat een set typen die zijn ontworpen om de ontwikkeling van uitbreiding van invoegtoepassingen te vereenvoudigen. De fundamentele eenheid van het .NET Framework-invoegtoepassingsmodel is het contract, waarmee wordt gedefinieerd hoe een hosttoepassing en een invoegtoepassing met elkaar communiceren. Een contract wordt blootgesteld aan een hosttoepassing met behulp van een hosttoepassingsspecifieke weergave van het contract. Op dezelfde manier wordt een invoegtoepassingsspecifieke weergave van het contract beschikbaar gesteld aan de invoegtoepassing. Een -adapter wordt gebruikt om een hosttoepassing en een invoegtoepassing toe te staan om te communiceren tussen de respectieve weergaven van het contract. Contracten, overzichten, en adapters worden segmenten genoemd en een groep van gerelateerde segmenten vormt een pijplijn. Pijplijnen vormen de basis waarop het .NET Framework-invoegtoepassingsmodel ondersteuning biedt voor detectie, activering, beveiligingsisolatie, uitvoeringsisolatie (zowel toepassingsdomeinen als processen), communicatie, levensduurbeheer en versiebeheer.

Met de som van deze ondersteuning kunnen ontwikkelaars invoegtoepassingen bouwen die kunnen worden geïntegreerd met de functionaliteit van een hosttoepassing. Voor sommige scenario's moeten hosttoepassingen echter gebruikersinterfaces weergeven die worden geleverd door invoegtoepassingen. Omdat elke presentatietechnologie in .NET Framework een eigen model heeft voor het implementeren van gebruikersinterfaces, biedt het .NET Framework-invoegtoepassingsmodel geen ondersteuning voor bepaalde presentatietechnologie. In plaats daarvan breidt WPF het .NET Framework-invoegtoepassingsmodel uit met ui-ondersteuning voor invoegtoepassingen.

WPF-Add-Ins

Met WPF, in combinatie met het .NET Framework-invoegtoepassingsmodel, kunt u een groot aantal scenario's aanpakken waarvoor hosttoepassingen gebruikersinterfaces uit invoegtoepassingen moeten weergeven. Deze scenario's worden met name behandeld door WPF met de volgende twee programmeermodellen:

  1. De invoegtoepassing retourneert een UI. Een invoegtoepassing retourneert een gebruikersinterface naar de hosttoepassing via een methodeaanroep, zoals gedefinieerd door het contract. Dit scenario wordt gebruikt in de volgende gevallen:

    • Het uiterlijk van een gebruikersinterface die wordt geretourneerd door een invoegtoepassing, is afhankelijk van gegevens of voorwaarden die alleen tijdens runtime bestaan, zoals dynamisch gegenereerde rapporten.

    • De gebruikersinterface voor services die worden geleverd door een invoegtoepassing verschilt van de gebruikersinterface van de hosttoepassingen die de invoegtoepassing kunnen gebruiken.

    • De invoegtoepassing voert voornamelijk een service uit voor de hosttoepassing en rapporteert de status aan de hosttoepassing met een gebruikersinterface.

  2. De invoegtoepassing is een ui-. Een invoegtoepassing is een gebruikersinterface, zoals gedefinieerd door het contract. Dit scenario wordt gebruikt in de volgende gevallen:

    • Een invoegtoepassing biedt geen andere services dan weergegeven, zoals een advertentie.

    • De gebruikersinterface voor services die worden geleverd door een invoegtoepassing is gebruikelijk voor alle hosttoepassingen die die invoegtoepassing kunnen gebruiken, zoals een calculator of kleurkiezer.

Voor deze scenario's moeten UI-objecten kunnen worden doorgegeven tussen hosttoepassings- en invoegtoepassingsdomeinen. Omdat het .NET Framework-invoegtoepassingsmodel gebruikmaakt van remoting om te communiceren tussen toepassingsdomeinen, moeten de objecten die worden doorgegeven op afstand toegankelijk zijn.

Een extern object is een exemplaar van een klasse die een of meer van de volgende handelingen doet:

Opmerking

Zie Objecten op afstand beschikbaar makenvoor meer informatie over het creëeren van op afstand beschikbare .NET Framework-objecten.

De WPF UI-typen zijn niet extern beschikbaar. Om het probleem op te lossen, breidt WPF het .NET Framework-invoegtoepassingsmodel uit om ervoor te zorgen dat de WPF-gebruikersinterface die is gemaakt door invoegtoepassingen, kan worden weergegeven vanuit hosttoepassingen. Deze ondersteuning wordt geleverd door WPF door twee typen: de INativeHandleContract-interface en twee statische methoden die zijn geïmplementeerd door de FrameworkElementAdapters klasse: ContractToViewAdapter en ViewToContractAdapter. Op hoog niveau worden deze typen en methoden op de volgende manier gebruikt:

  1. WPF vereist dat gebruikersinterfaces die worden geleverd door invoegtoepassingen klassen zijn die rechtstreeks of indirect zijn afgeleid van FrameworkElement, zoals vormen, besturingselementen, gebruikersbesturingselementen, indelingsvensters en pagina's.

  2. Waar het contract ook declareert dat een gebruikersinterface wordt doorgegeven tussen de invoegtoepassing en de hosttoepassing, moet deze worden gedeclareerd als een INativeHandleContract (geen FrameworkElement); INativeHandleContract is een externe weergave van de gebruikersinterface van de invoegtoepassing die kan worden doorgegeven over isolatiegrenzen.

  3. Voordat deze wordt doorgegeven vanuit het toepassingsdomein van de invoegtoepassing, wordt een FrameworkElement verpakt als een INativeHandleContract door ViewToContractAdapteraan te roepen.

  4. Nadat deze is doorgegeven aan het toepassingsdomein van de hosttoepassing, moet de INativeHandleContract opnieuw worden verpakt als een FrameworkElement door ContractToViewAdapteraan te roepen.

Hoe INativeHandleContract, ContractToViewAdapteren ViewToContractAdapter worden gebruikt, is afhankelijk van het specifieke scenario. De volgende secties bevatten details voor elk programmeermodel.

Add-In retourneert een gebruikersinterface

Voor een invoegtoepassing om een gebruikersinterface te retourneren aan een hosttoepassing, is het volgende vereist:

  1. De hosttoepassing, invoegtoepassing en pijplijn moeten worden gemaakt, zoals beschreven in de documentatie voor .NET Framework invoegtoepassingen en uitbreidbaarheid.

  2. Het contract moet IContract implementeren en om een gebruikersinterface te retourneren, moet het contract een methode declareren met een retourwaarde van het type INativeHandleContract.

  3. De gebruikersinterface die wordt doorgegeven tussen de invoegtoepassing en de hosttoepassing, moet direct of indirect worden afgeleid van FrameworkElement.

  4. De gebruikersinterface die door de invoegtoepassing wordt geretourneerd, moet worden geconverteerd van een FrameworkElement naar een INativeHandleContract voordat de isolatiegrens wordt overschreden.

  5. De geretourneerde gebruikersinterface moet worden geconverteerd van een INativeHandleContract naar een FrameworkElement nadat de isolatiegrens is overschreden.

  6. De hosttoepassing geeft de geretourneerde FrameworkElementweer.

Zie voor een voorbeeld dat laat zien hoe u een invoegtoepassing implementeert die een gebruikersinterface retourneert, Een Add-In maken die een ui-retourneert.

Add-In is een gebruikersinterface

Wanneer een invoegtoepassing een gebruikersinterface is, zijn de volgende vereisten vereist:

  1. De hosttoepassing, invoegtoepassing en pijplijn moeten worden gemaakt, zoals beschreven in de documentatie voor .NET Framework invoegtoepassingen en uitbreidbaarheid.

  2. De contractinterface voor de invoegtoepassing moet INativeHandleContractimplementeren.

  3. De invoegtoepassing die aan de hosttoepassing wordt doorgegeven, moet direct of indirect worden afgeleid van FrameworkElement.

  4. De invoegtoepassing moet worden geconverteerd van een FrameworkElement naar een INativeHandleContract voordat de isolatiegrens wordt overschreden.

  5. De invoegtoepassing moet worden geconverteerd van een INativeHandleContract naar een FrameworkElement nadat de isolatiegrens is overschreden.

  6. De hosttoepassing geeft de geretourneerde FrameworkElementweer.

Zie voor een voorbeeld dat laat zien hoe u een invoegtoepassing implementeert die een gebruikersinterface is, Een Add-In maken die een gebruikersinterfaceis.

Meerdere UI's retourneren vanuit de Add-In

Invoegtoepassingen bieden vaak meerdere gebruikersinterfaces om hosttoepassingen weer te geven. Denk bijvoorbeeld aan een invoegtoepassing die een gebruikersinterface is die ook statusinformatie biedt aan de hosttoepassing, ook als een gebruikersinterface. Een invoegtoepassing zoals deze kan worden geïmplementeerd met behulp van een combinatie van technieken uit zowel de Add-In Retourneert een Gebruikersinterface als Add-In Is een Gebruikersinterface modellen.

Add-Ins- en XAML-browsertoepassingen

In de voorbeelden tot nu toe is de hosttoepassing een geïnstalleerde zelfstandige toepassing. Maar XAML-browsertoepassingen (XBAPs) kunnen ook invoegtoepassingen hosten, zij het met de volgende aanvullende vereisten voor bouwen en implementeren:

  • Het XBAP-toepassingsmanifest moet op een specifieke manier worden geconfigureerd om de pijplijncomponenten (zoals mappen en assembly's) en de assembly van de invoegtoepassing te downloaden naar de ClickOnce-cache voor toepassingen op de clientcomputer, in dezelfde map als de XBAP.

  • De XBAP-code voor het detecteren en laden van invoegtoepassingen moet gebruikmaken van de ClickOnce-toepassingscache voor de XBAP als de pijplijn en invoegtoepassingslocatie.

  • De XBAP moet de invoegtoepassing laden in een speciale beveiligingscontext als de invoegtoepassing verwijst naar losse bestanden die zich op de locatie van oorsprong bevinden; wanneer invoegtoepassingen worden gehost door XBAPs, kunnen alleen verwijzen naar losse bestanden die zich op de site van oorsprong van de hosttoepassing bevinden.

Deze taken worden gedetailleerd beschreven in de volgende subsecties.

De pijplijn en Add-In configureren voor ClickOnce-implementatie

XBAPs worden gedownload naar en uitgevoerd vanuit een veilige map in de ClickOnce-implementatiecache. Om een invoegtoepassing in een XBAP te hosten, moeten de pijplijn en de assembly ook worden gedownload naar de veilige map. Hiervoor moet u het toepassingsmanifest configureren zodat deze zowel de pipeline als de add-in assembly opneemt om te downloaden. Dit is het eenvoudigst in Visual Studio, hoewel de pijplijn en invoegtoepassingsassembly zich in de hoofdmap van het XBAP-hostproject moeten bevinden, zodat Visual Studio de pijplijnassembly's kan detecteren.

Daarom is de eerste stap het bouwen van de pijplijn en het toevoegen van de assemblies aan de hoofdmap van het XBAP-project door de uitvoerinstellingen van elk pijplijnassembly- en invoegtoepassingsassemblyproject in te stellen. In de volgende tabel ziet u de uitvoerpaden voor pijplijnassemblyprojecten en invoegtoepassingsassemblyproject die zich in dezelfde oplossing en hoofdmap bevinden als het XBAP-hostproject.

Tabel 1: Uitvoerpaden bouwen voor de pijplijnassembly's die worden gehost door een XBAP

Project pijpleidingassemblage Uitvoerpad bouwen
Overeenkomst ..\HostXBAP\Contracts\
Add-In weergave ..\HostXBAP\AddInViews\
Voeg adapterIn-Side toe ..\HostXBAP\AddInSideAdapters\
Host-Side adapter ..\HostXBAP\HostSideAdapters\
Add-In ..\HostXBAP\AddIns\WPFAddIn1

De volgende stap bestaat uit het opgeven van de pijplijnassembly's en de invoegtoepassingsassembly als de XBAPs-inhoudsbestanden in Visual Studio door het volgende te doen:

  1. Neem de pipeline en add-in assembly op in het project door met de rechtermuisknop op elke pipeline-map in Solution Explorer te klikken en Opnemen in Projectte kiezen.

  2. Stel de Build Action van elke pijplijnassembly en invoegtoepassingsassembly in op Inhoud vanuit het venster Eigenschappen.

De laatste stap is het configureren van het toepassingsmanifest om de assemblybestanden voor de pijplijn en het bestand voor de invoegtoepassing bij de download op te nemen. De bestanden moeten zich bevinden in mappen in de hoofdmap van de map in de ClickOnce-cache die de XBAP-toepassing in beslag neemt. De configuratie kan worden bereikt in Visual Studio door het volgende te doen:

  1. Klik met de rechtermuisknop op het XBAP-project, klik op Eigenschappen, klik op Publicerenen klik vervolgens op de knop Application Files.

  2. Stel in het dialoogvenster Toepassingsbestanden de Publicatiestatus van elke pijplijn en invoegtoepassing DLL in op Opnemen (automatisch)en stel voor elke pijplijn en invoegtoepassing DLL de Downloadgroep in op (vereist).

De pijplijn en Add-In gebruiken vanuit de applicatiebasis

Wanneer de pijplijn en invoegtoepassing zijn geconfigureerd voor ClickOnce-implementatie, worden ze gedownload naar dezelfde ClickOnce-cachemap als de XBAP-toepassing. Als u de pijplijn en invoegtoepassing van de XBAP wilt gebruiken, moet de XBAP-code deze ophalen uit de toepassingsbasis. De verschillende typen en leden van het .NET Framework-invoegtoepassingsmodel voor het gebruik van pijplijnen en invoegtoepassingen bieden speciale ondersteuning voor dit scenario. Ten eerste wordt het pad geïdentificeerd door de ApplicationBase opsommingswaarde. U gebruikt deze waarde met overbelastingen van de relevante invoegtoepassingsleden voor het gebruik van pijplijnen die het volgende bevatten:

Toegang tot de site van de host van oorsprong

Om ervoor te zorgen dat een invoegtoepassing kan verwijzen naar bestanden van de oorspronkelijke site, moet de invoegtoepassing worden geladen met beveiligingsisolatie die gelijk is aan de hosttoepassing. Dit beveiligingsniveau wordt geïdentificeerd door de AddInSecurityLevel.Host opsommingswaarde en doorgegeven aan de Activate methode wanneer een invoegtoepassing wordt geactiveerd.

WPF Add-In-architectuur

Zoals we hebben gezien, stelt WPF .NET Framework-invoegtoepassingen in staat om gebruikersinterfaces (die direct of indirect zijn afgeleid van FrameworkElement) te implementeren met behulp van INativeHandleContract, ViewToContractAdapter en ContractToViewAdapter. Het resultaat is dat de hosttoepassing een FrameworkElement retourneert die wordt weergegeven vanuit de gebruikersinterface in de hosttoepassing.

Voor eenvoudige ui-invoegtoepassingsscenario's is dit net zo gedetailleerd als een ontwikkelaar nodig heeft. Voor complexere scenario's, met name voor scenario's die extra WPF-services proberen te gebruiken, zoals indeling, resources en gegevensbinding, is gedetailleerdere kennis van hoe WPF het .NET Framework-invoegtoepassingsmodel uitbreidt met ui-ondersteuning is vereist om inzicht te krijgen in de voordelen en beperkingen.

WpF geeft in principe geen gebruikersinterface door van een invoegtoepassing aan een hosttoepassing; In plaats daarvan geeft WPF de Win32-venstergreep voor de gebruikersinterface door met behulp van WPF-interoperabiliteit. Als een gebruikersinterface van een invoegtoepassing wordt doorgegeven aan een hosttoepassing, gebeurt het volgende:

  • Aan de kant van de invoegtoepassing verkrijgt WPF een window handle voor de gebruikersinterface die wordt weergegeven door de hosttoepassing. De venstergreep wordt ingekapseld door een interne WPF-klasse die is afgeleid van HwndSource en implementeert INativeHandleContract. Een exemplaar van deze klasse wordt geretourneerd door ViewToContractAdapter en wordt verplaatst van het toepassingsdomein van de invoegtoepassing naar het toepassingsdomein van de hosttoepassing.

  • Aan de hosttoepassingszijde verpakt WPF de HwndSource opnieuw als een interne WPF-klasse die is afgeleid van HwndHost en INativeHandleContractverbruikt. Een exemplaar van deze klasse wordt geretourneerd door ContractToViewAdapter aan de hosttoepassing.

HwndHost bestaat om gebruikersinterfaces weer te geven, geïdentificeerd door venstergrepen, van WPF-gebruikersinterfaces. Zie WPF en Win32 Interoperationvoor meer informatie.

Kortom, INativeHandleContract, ViewToContractAdapteren ContractToViewAdapter bestaan om toe te staan dat de venstergreep voor een WPF-gebruikersinterface wordt doorgegeven vanuit een invoegtoepassing aan een hosttoepassing, waar deze wordt ingekapseld door een HwndHost en de gebruikersinterface van de hosttoepassing wordt weergegeven.

Opmerking

Omdat de hosttoepassing een HwndHostkrijgt, kan de hosttoepassing het object dat wordt geretourneerd door ContractToViewAdapter niet converteren naar het type dat wordt geïmplementeerd door de invoegtoepassing (bijvoorbeeld een UserControl).

Wat de aard ervan is, heeft HwndHost bepaalde beperkingen die van invloed zijn op de wijze waarop hosttoepassingen deze kunnen gebruiken. WPF breidt echter HwndHost uit met verschillende functies voor invoegscenario's. Deze voordelen en beperkingen worden hieronder beschreven.

WPF-Add-In voordelen

Omdat WPF-invoegtoepassingsgebruikersinterfaces worden weergegeven vanuit hosttoepassingen met behulp van een interne klasse die is afgeleid van HwndHost, worden deze gebruikersinterfaces beperkt door de mogelijkheden van HwndHost met betrekking tot WPF UI-services zoals indeling, rendering, gegevensbinding, stijlen, sjablonen en resources. WPF breidt echter de interne HwndHost subklasse uit met aanvullende mogelijkheden die het volgende omvatten:

  • Tabben tussen de gebruikersinterface van een hosttoepassing en de gebruikersinterface van een invoegtoepassing. Houd er rekening mee dat het programmeermodel "invoegtoepassing als gebruikersinterface" vereist dat de adapter aan de add-in-kant QueryContract overschrijft om tabben mogelijk te maken, ongeacht of de invoegtoepassing volledig of gedeeltelijk vertrouwd is.

  • Voldoen aan toegankelijkheidsvereisten voor gebruikersinterfaces voor invoegtoepassingen die worden weergegeven vanuit gebruikersinterfaces van hosttoepassingen.

  • WPF-toepassingen veilig laten uitvoeren in meerdere toepassingsdomeinscenario's.

  • Voorkomen dat illegale toegang tot het UI-venster van de invoegtoepassing wordt verwerkt wanneer invoegtoepassingen worden uitgevoerd met beveiligingsisolatie (dat wil zeggen een gedeeltelijke vertrouwens-beveiligingssandbox). Het aanroepen van ViewToContractAdapter zorgt voor deze beveiliging:

    • Voor het programmeermodel 'invoegtoepassing retourneert een UI', is het aanroepen van ViewToContractAdapterde enige manier om de venstergreep voor een invoegtoepassingsinterface door te geven.

    • Voor het programmeermodel 'invoegtoepassing is een gebruikersinterface' moet QueryContract worden overschreven op de adapter aan de invoegtoepassing en moet ViewToContractAdapter worden aangeroepen (zoals weergegeven in de eerdere voorbeelden), net als het aanroepen van de QueryContract-implementatie van de adapter aan de hostzijde.

  • Het bieden van beveiliging tegen uitvoering van meerdere toepassingsdomeinen. Vanwege beperkingen van toepassingsdomeinen veroorzaken niet-afgehandelde uitzonderingen die in invoegtoepassingsdomeinen optreden, dat de hele toepassing vastloopt, hoewel de isolatiegrens bestaat. WPF en het .NET Framework-invoegtoepassingsmodel bieden echter een eenvoudige manier om dit probleem te omzeilen en de stabiliteit van toepassingen te verbeteren. Een WPF-invoegtoepassing waarin een gebruikersinterface wordt weergegeven, maakt een Dispatcher voor de thread waarop het toepassingsdomein wordt uitgevoerd, als de hosttoepassing een WPF-toepassing is. U kunt alle niet-verwerkte uitzonderingen in het toepassingsdomein detecteren door de UnhandledException-gebeurtenis in de Dispatchervan de WPF-invoegtoepassing te verwerken. U kunt de Dispatcher ophalen uit de eigenschap CurrentDispatcher.

Beperkingen voor WPF-Add-In

Naast de voordelen die WPF toevoegt aan het standaardgedrag dat wordt geleverd door HwndSource, HwndHosten venstergrepen, zijn er ook beperkingen voor gebruikersinterfaces voor invoegtoepassingen die worden weergegeven vanuit hosttoepassingen:

  • Gebruikersinterfaces van invoegtoepassingen die worden weergegeven vanuit een hosttoepassing, respecteren het uitknipgedrag van de hosttoepassing niet.

  • Het concept van luchtruim in interoperabiliteitsscenario's is ook van toepassing op invoegtoepassingen (zie Overzicht van technologieregio's).

  • De UI-services van een hosttoepassing, zoals overname van resources, gegevensbinding en opdrachten, zijn niet automatisch beschikbaar voor gebruikersinterfaces van invoegtoepassingen. Als u deze services aan de invoegtoepassing wilt leveren, moet u de pijplijn bijwerken.

  • Een invoegtoepassingsinterface kan niet worden gedraaid, geschaald, scheefgetrokken of anderszins beïnvloed door een transformatie (zie Overzicht van transformaties).

  • Inhoud in gebruikersinterfaces van invoegtoepassingen die worden weergegeven door tekenbewerkingen uit de System.Drawing-naamruimte kan alfamenging bevatten. Zowel een gebruikersinterface voor invoegtoepassingen als de gebruikersinterface van de hosttoepassing die deze bevat, moet echter 100% ondoorzichtig zijn; met andere woorden, de eigenschap Opacity op beide moet worden ingesteld op 1.

  • Als de eigenschap AllowsTransparency van een venster in de hosttoepassing met een invoegtoepassingsinterface is ingesteld op true, is de invoegtoepassing onzichtbaar. Dit geldt zelfs als de gebruikersinterface van de invoegtoepassing 100% ondoorzichtig is (de eigenschap Opacity een waarde van 1 heeft).

  • Er moet een invoegtoepassingsinterface worden weergegeven boven op andere WPF-elementen in hetzelfde venster op het hoogste niveau.

  • Er kan geen gedeelte van de gebruikersinterface van een invoegtoepassing worden weergegeven met behulp van een VisualBrush. In plaats daarvan kan de invoegtoepassing een momentopname maken van de gegenereerde gebruikersinterface om een bitmap te maken die kan worden doorgegeven aan de hosttoepassing met behulp van methoden die door het contract zijn gedefinieerd.

  • Mediabestanden kunnen niet worden afgespeeld vanuit een MediaElement in een gebruikersinterface van een invoegtoepassing.

  • Muisgebeurtenissen die worden gegenereerd voor de gebruikersinterface van de invoegtoepassing, worden niet ontvangen of gegenereerd door de hosttoepassing en de eigenschap IsMouseOver voor de gebruikersinterface van de hosttoepassing heeft een waarde van false.

  • Wanneer de focus verschuift tussen controles in een invoegtoepassing-UI, worden de gebeurtenissen GotFocus en LostFocus niet ontvangen of verhoogd door de hosttoepassing.

  • Het gedeelte van een hosttoepassing met een invoegtoepassingsinterface wordt wit weergegeven wanneer deze wordt afgedrukt.

  • Alle dispatchers (zie Dispatcher) die door de gebruikersinterface van de invoegtoepassing zijn gemaakt, moeten handmatig worden afgesloten voordat de invoegtoepassing eigenaar wordt verwijderd als de hosttoepassing doorgaat met de uitvoering. Het contract kan methoden implementeren waarmee de hosttoepassing de invoegtoepassing kan signaleren voordat de invoegtoepassing wordt ontladen, waardoor de gebruikersinterface van de invoegtoepassing haar dispatchers kan afsluiten.

  • Als een gebruikersinterface van een invoegtoepassing een InkCanvas is of een InkCanvasbevat, kunt u de invoegtoepassing niet ontladen.

Prestatieoptimalisatie

Wanneer er meerdere toepassingsdomeinen worden gebruikt, worden de verschillende .NET Framework-assembly's die vereist zijn voor elke toepassing, allemaal in het domein van die toepassing geladen. Als gevolg hiervan kan de tijd die nodig is voor het maken van nieuwe toepassingsdomeinen en het starten van toepassingen in deze domeinen de prestaties beïnvloeden. Het .NET Framework biedt echter een manier om de begintijden te verminderen door toepassingen te instrueren assembly's te delen tussen toepassingsdomeinen als ze al zijn geladen. U doet dit met behulp van het kenmerk LoaderOptimizationAttribute, dat moet worden toegepast op de invoerpuntmethode (Main). In dit geval moet u alleen code gebruiken om uw toepassingsdefinitie te implementeren (zie Application Management Overview).

Zie ook

  • Last updated on