Översikt över WPF Add-Ins

.NET Framework innehåller en tilläggsmodell som utvecklare kan använda för att skapa program som stöder utökningsbarhet för tillägg. Med den här tilläggsmodellen kan du skapa tillägg som integreras med och utökar programfunktionerna. I vissa scenarier måste program också visa användargränssnitt som tillhandahålls av tillägg. Det här avsnittet visar hur WPF utökar .NET Framework-tilläggsmodellen för att aktivera dessa scenarier, arkitekturen bakom den, dess fördelar och dess begränsningar.

Förutsättningar

Förtrogenhet med .NET Framework-tilläggsmodellen krävs. Mer information finns i Tillägg och utökningsbarhet.

översikt över Add-Ins

För att undvika komplexiteten i programkompilering och omdistribution för att införliva nya funktioner implementerar program utökningsmekanismer som gör det möjligt för utvecklare (både första part och tredje part) att skapa andra program som integreras med dem. Det vanligaste sättet att stödja den här typen av utökningsbarhet är att använda tillägg (kallas även "tillägg" och "plugin-program"). Exempel på verkliga program som exponerar utökningsbarhet med tillägg är:

• Internet Explorer-tillägg.

• Windows Media Player-tillägg.

• Visual Studio-tillägg.

Till exempel tillåter Windows Media Player-tilläggsmodellen tredjepartsutvecklare att implementera "plugin-program" som utökar Windows Media Player på flera olika sätt, inklusive att skapa avkodare och kodare för medieformat som inte stöds internt av Windows Media Player (till exempel DVD, MP3), ljudeffekter och skinn. Varje tilläggsmodell är byggd för att exponera de funktioner som är unika för ett program, även om det finns flera entiteter och beteenden som är gemensamma för alla tilläggsmodeller.

De tre viktigaste entiteterna för typiska utökningslösningar för tillägg är kontrakt, tillägg och värdprogram. Kontrakt definierar hur tillägg integreras med värdprogram på två sätt:

• Tillägg integreras med funktioner som implementeras av värdprogram.

• Värdprogram exponerar funktioner för tillägg att integrera med.

För att tillägg ska kunna användas måste värdprogram hitta dem och ladda dem vid körning. Därför har program som stöder tillägg följande ytterligare ansvarsområden:

• Upptäckt: Att hitta tillägg som följer kontrakt som stöds av värdprogram.

• Aktivering: Läsa in, köra och upprätta kommunikation med tillägg.

• Isolering: Använda antingen programdomäner eller processer för att upprätta isoleringsgränser som skyddar program från potentiella säkerhets- och körningsproblem med tillägg.

• Kommunikation: Tillåta att tillägg och värdprogram kommunicerar med varandra över isoleringsgränser genom att anropa metoder och skicka data.

• Livslängdshantering: Läsa in och ta bort programdomäner och processer på ett rent och förutsägbart sätt (se Programdomäner).

• Versionshantering: Se till att värdprogram och tillägg fortfarande kan kommunicera när nya versioner av någon av dem skapas.

I slutändan är det ett icke-trivialt åtagande att utveckla en robust tilläggsmodell. Därför tillhandahåller .NET Framework en infrastruktur för att skapa tilläggsmodeller.

Översikt över .NET Framework Add-In Model

.NET Framework-tilläggsmodellen, som finns i System.AddIn namnområdet, innehåller en uppsättning typer som är utformade för att förenkla utvecklingen av utökningsbarhet för tillägg. Den grundläggande enheten i .NET Framework-tilläggsmodellen är kontraktet, som definierar hur ett värdprogram och ett tillägg kommunicerar med varandra. Ett kontrakt exponeras för ett värdprogram med hjälp av en värdprogramspecifik vy av kontraktet. På samma sätt görs en tilläggsspecifik vy av kontraktet tillgänglig för tillägget. En adapter används för att låta ett värdprogram och ett tillägg kommunicera mellan sina respektive vyer av kontrakten. Kontrakt, vyer och adaptrar benämns segment, och en uppsättning relaterade segment utgör en pipeline. Pipelines är grunden där .NET Framework-tilläggsmodellen stöder identifiering, aktivering, säkerhetsisolering, körningsisolering (med både programdomäner och processer), kommunikation, livslängdshantering och versionshantering.

Summan av det här stödet gör att utvecklare kan skapa tillägg som integreras med funktionerna i ett värdprogram. Vissa scenarier kräver dock att värdprogram visar användargränssnitt som tillhandahålls av tillägg. Eftersom varje presentationsteknik i .NET Framework har en egen modell för att implementera användargränssnitt stöder .NET Framework-tilläggsmodellen inte någon särskild presentationsteknik. I stället utökar WPF .NET Framework-tilläggsmodellen med användargränssnittsstöd för tillägg.

WPF-Add-Ins

MED WPF kan du tillsammans med .NET Framework-tilläggsmodellen hantera en mängd olika scenarier som kräver att värdprogram visar användargränssnitt från tillägg. I synnerhet behandlas dessa scenarier av WPF med följande två programmeringsmodeller:

1. Tillägget returnerar ett användargränssnitt. Ett tillägg returnerar ett användargränssnitt till värdprogrammet via ett metodanrop, enligt definitionen i kontraktet. Det här scenariot används i följande fall:

   • Utseendet på ett användargränssnitt som returneras av ett tillägg beror på antingen data eller villkor som endast finns vid körning, till exempel dynamiskt genererade rapporter.

   • Användargränssnittet för tjänster som tillhandahålls av ett tillägg skiljer sig från användargränssnittet för de värdprogram som kan använda tillägget.

   • Tillägget utför främst en tjänst för värdprogrammet och rapporterar status till värdprogrammet med ett användargränssnitt.

2. Tillägget är ett användargränssnitt. Ett tillägg är ett användargränssnitt som definieras av kontraktet. Det här scenariot används i följande fall:

   • Ett tillägg tillhandahåller inte andra tjänster än att visas, till exempel en annons.

   • Användargränssnittet för tjänster som tillhandahålls av ett tillägg är gemensamt för alla värdprogram som kan använda tillägget, till exempel en kalkylator eller färgväljare.

Dessa scenarier kräver att gränssnittsobjekt kan skickas mellan värdprogram och tilläggsprogramdomäner. Eftersom .NET Framework-tilläggsmodellen förlitar sig på fjärrkommunikation för att kommunicera mellan programdomäner måste de objekt som skickas mellan dem vara fjärrkommunikationsbara.

Ett fjärranslutningsbart objekt är en instans av en klass som gör något av följande:

• Härleds från MarshalByRefObject klassen.

• Implementerar ISerializable-gränssnittet.

• Har attributet SerializableAttribute tillämpats.

WPF-användargränssnittstyperna kan inte fjärraktiveras. För att lösa problemet utökar WPF .NET Framework-tilläggsmodellen för att aktivera WPF-användargränssnitt som skapats av tillägg som ska visas från värdprogram. Det här stödet tillhandahålls av WPF av två typer: INativeHandleContract gränssnittet och två statiska metoder som implementeras av FrameworkElementAdapters klassen: ContractToViewAdapter och ViewToContractAdapter. På hög nivå används dessa typer och metoder på följande sätt:

1. WPF kräver att användargränssnitt som tillhandahålls av tillägg är klasser som direkt eller indirekt härleds från FrameworkElement, till exempel former, kontroller, användarkontroller, layoutpaneler och sidor.

2. Oavsett var kontraktet deklarerar att ett användargränssnitt skickas mellan tillägget och värdprogrammet måste det deklareras som en INativeHandleContract (inte en FrameworkElement); INativeHandleContract är en fjärrkommunikationsbar representation av tilläggets användargränssnitt som kan skickas över isoleringsgränser.

3. Innan det skickas från tilläggets programdomän paketeras en FrameworkElement som en INativeHandleContract genom att anropa ViewToContractAdapter.

4. Efter att ha skickats till värdprogrammets programdomän INativeHandleContract måste paketeras om som en FrameworkElement genom att anropa ContractToViewAdapter.

Hur INativeHandleContract, ContractToViewAdapteroch ViewToContractAdapter används beror på det specifika scenariot. Följande avsnitt innehåller information om varje programmeringsmodell.

Add-In returnerar ett användargränssnitt

För att ett tillägg ska returnera ett användargränssnitt till ett värdprogram krävs följande:

1. Värdprogrammet, tillägget och pipelinen måste skapas enligt beskrivningen i dokumentationen om .NET Framework-tillägg och Utökningsbarhet .

2. Kontraktet måste implementera IContract och för att returnera ett användargränssnitt måste kontraktet deklarera en metod med ett returvärde av typen INativeHandleContract.

3. Användargränssnittet som skickas mellan tillägget och värdprogrammet måste direkt eller indirekt härledas från FrameworkElement.

4. Användargränssnittet som returneras av tillägget måste konverteras från en FrameworkElement till en INativeHandleContract innan den passerar isoleringsgränsen.

5. Användargränssnittet som returneras måste konverteras från en INativeHandleContract till en FrameworkElement efter att isoleringsgränsen har passerats.

6. Värdprogrammet visar den returnerade FrameworkElement.

Ett exempel som visar hur du implementerar ett tillägg som returnerar ett användargränssnitt finns i Skapa en Add-In som returnerar ett användargränssnitt.

Add-In är ett användargränssnitt

När ett tillägg är ett användargränssnitt krävs följande:

1. Värdprogrammet, tillägget och pipelinen måste skapas enligt beskrivningen i dokumentationen om .NET Framework-tillägg och Utökningsbarhet .

2. Kontraktsgränssnittet för tillägget måste implementera INativeHandleContract.

3. Tillägget som skickas till värdprogrammet måste direkt eller indirekt härledas från FrameworkElement.

4. Tillägget måste konverteras från en FrameworkElement till en INativeHandleContract innan isoleringsgränsen korsas.

5. Tillägget måste konverteras från en INativeHandleContract till en FrameworkElement efter att isoleringsgränsen har korsats.

6. Värdprogrammet visar den returnerade FrameworkElement.

Ett exempel som visar hur du implementerar ett tillägg som är ett användargränssnitt finns i Skapa en Add-In som är ett användargränssnitt.

Returnera flera användargränssnitt från en Add-In

Tillägg tillhandahåller ofta flera användargränssnitt som värdprogram kan visa. Anta till exempel att ett tillägg är ett användargränssnitt som även tillhandahåller statusinformation till värdprogrammet, även som ett användargränssnitt. Ett tillägg som detta kan implementeras med hjälp av en kombination av tekniker från både Add-In Returnerar ett användargränssnitt och Add-In Är en användargränssnittsmodell .

Add-Ins- och XAML-webbläsarprogram

I exemplen hittills har värdprogrammet varit ett installerat fristående program. Men XAML-webbläsarprogram (XBAPs) kan också vara värdar för tillägg, om än med följande ytterligare krav för bygg- och implementering:

• XBAP-programmanifestet måste konfigureras särskilt för att ladda ned pipelinen (mappar och sammansättningar) och tilläggssammansättningen till ClickOnce-programcachen på klientdatorn, i samma mapp som XBAP.

• XBAP-koden för att identifiera och läsa in tillägg måste använda ClickOnce-programcachen för XBAP som pipeline- och tilläggsplats.

• XBAP måste läsa in tillägget i en särskild säkerhetskontext om tillägget refererar till lösa filer som finns på ursprungsplatsen. när de hanteras av XBAP:er kan tillägg endast referera till lösa filer som finns på värdprogrammets ursprungsplats.

Dessa uppgifter beskrivs i detalj i följande underavsnitt.

Konfigurera pipelinen och Add-In för ClickOnce-distribution

XBAP:er laddas ned till och körs från en säker mapp i ClickOnce-distributionscachen. För att en XBAP ska vara värd för ett tillägg måste även pipeline- och tilläggssammansättningen laddas ned till den säkra mappen. För att uppnå detta måste du konfigurera programmanifestet så att det inkluderar både pipeline- och tilläggssammansättningen för nedladdning. Detta görs enklast i Visual Studio, även om pipeline- och tilläggssammansättningen måste finnas i rotmappen för XBAP-projektet för att Visual Studio ska kunna identifiera pipelinesammansättningarna.

Det första steget är därför att skapa pipeline och tilläggskomponent till XBAP-projektets rot genom att ange byggutdata för varje pipelinesammansättning och tilläggskomponentsprojekt. I följande tabell visas byggutdatasökvägarna för pipelinemonteringsprojekt och tilläggssammansättningsprojekt som finns i samma lösning och rotmapp som värd-XBAP-projektet.

Tabell 1: Skapa utdatasökvägar för pipelinesammansättningar som hanteras av en XBAP

Nästa steg är att ange pipeline-assembly och add-in-assembly som XBAP-innehållsfiler i Visual Studio så här:

1. Inkludera pipeline- och tilläggssammansättningen i projektet genom att högerklicka på varje pipelinemapp i Solution Explorer och välja Inkludera i projekt.

2. Ange build-åtgärden för varje pipelinesammansättning och tilläggssammansättning till Innehåll från fönstret Egenskaper .

Det sista steget är att konfigurera programmanifestet så att det innehåller pipelinens sammansättningsfiler och tilläggssammansättningsfilen för nedladdning. Filerna ska finnas i mapparna i roten av mappen i ClickOnce-cachen som XBAP-programmet upptar. Konfigurationen kan uppnås i Visual Studio genom att göra följande:

1. Högerklicka på XBAP-projektet, klicka på Egenskaper, klicka på Publicera och klicka sedan på knappen Programfiler .

2. I dialogrutan Programfiler anger du Publiceringsstatus för varje pipeline och tilläggs-DLL till Inkludera (automatiskt) och anger nedladdningsgruppen för varje pipeline och tilläggs-DLL till (obligatoriskt).

Använda pipelinen och Add-In från programbasen

När pipelinen och tillägget har konfigurerats för ClickOnce-distributionen laddas de ned till samma ClickOnce-cachemapp som XBAP. Om du vill använda pipelinen och tillägget från XBAP måste XBAP-koden hämta dem från programbasen. De olika typerna och medlemmarna i .NET Framework-tilläggsmodellen för användning av pipelines och tillägg ger särskilt stöd för det här scenariot. För det första identifieras sökvägen av ApplicationBase uppräkningsvärdet. Du använder det här värdet med överbelastningar av de relevanta tilläggsmedlemmarna för att använda pipeliner som innehåller följande:

• AddInStore.FindAddIns(Type, PipelineStoreLocation)

• AddInStore.FindAddIns(Type, PipelineStoreLocation, String[])

• AddInStore.Rebuild(PipelineStoreLocation)

• AddInStore.Update(PipelineStoreLocation)

Åtkomst till värdens ursprungswebbplats

För att säkerställa att ett tillägg kan referera till filer från ursprungsplatsen måste tillägget läsas in med säkerhetsisolering som motsvarar värdapplikationen. Den här säkerhetsnivån identifieras av uppräkningsvärdet AddInSecurityLevel.Host och skickas till Activate metoden när ett tillägg aktiveras.

WPF Add-In-arkitektur

På den högsta nivån, som vi har sett, gör WPF det möjligt för .NET Framework-tillägg att implementera användargränssnitt (som härleds direkt eller indirekt från FrameworkElement) med hjälp av INativeHandleContract, ViewToContractAdapter och ContractToViewAdapter. Resultatet är att värdprogrammet får tillbaka en FrameworkElement som visas i användargränssnittet i värdprogrammet.

För enkla UI-tilläggsscenarier är detta så mycket detaljer som en utvecklare behöver. För mer komplexa scenarier, särskilt de som försöker använda ytterligare WPF-tjänster som layout, resurser och databindning, krävs mer detaljerad kunskap om hur WPF utökar .NET Framework-tilläggsmodellen med stöd för användargränssnittet för att förstå dess fördelar och begränsningar.

I grunden skickar WPF inte ett användargränssnitt från ett tillägg till ett värdprogram. I stället skickar WPF Win32-fönsterhandtaget för användargränssnittet med hjälp av WPF-samverkan. När ett användargränssnitt från ett tillägg skickas till ett värdprogram sker följande:

• På tilläggssidan hämtar WPF ett fönsterhandtag för användargränssnittet som ska visas av värdprogrammet. Fönsterhandtaget kapslas in av en intern WPF-klass som härleds från HwndSource och implementerar INativeHandleContract. En instans av den här klassen returneras av ViewToContractAdapter och konverteras från tilläggets programdomän till värdprogrammets programdomän.

• På värdprogramsidan paketerar HwndSource WPF om som en intern WPF-klass som härleds från HwndHost och använder INativeHandleContract. En instans av den här klassen returneras av ContractToViewAdapter till värdprogrammet.

HwndHost finns för att visa användargränssnitt, som identifieras av fönsterhandtag, från WPF-användargränssnitt. Mer information finns i WPF och Win32 Interoperation.

Sammanfattningsvis INativeHandleContract, ViewToContractAdapter, och ContractToViewAdapter finns för att tillåta att fönsterhandtaget för ett WPF-användargränssnitt skickas från ett tillägg till ett värdprogram, där det kapslas in av ett HwndHost och visar värdprogrammets användargränssnitt.

Av sin natur HwndHost har vissa begränsningar som påverkar hur värdprogram kan använda dem. WPF utökas HwndHost dock med flera funktioner för tilläggsscenarier. Dessa fördelar och begränsningar beskrivs nedan.

WPF-Add-In fördelar

Eftersom WPF-tilläggsanvändargränssnitt visas från värdprogram med hjälp av en intern klass som härleds från HwndHostbegränsas dessa användargränssnitt av funktionerna HwndHost i när det gäller WPF UI-tjänster som layout, rendering, databindning, formatmallar, mallar och resurser. WPF utökar dock sin interna HwndHost underklass med ytterligare funktioner som omfattar följande:

• Tabbing mellan ett värdprograms användargränssnitt och ett tilläggs användargränssnitt. Observera att programmeringsmodellen "insticksprogrammet är en UI" kräver att insticksprogramsadaptern åsidosätter QueryContract för att aktivera tabbning, oavsett om insticksprogrammet är fullständigt betrott eller delvis betrott.

• Uppfylla tillgänglighetskraven för tilläggsanvändargränssnitt som visas från värdprogrammets användargränssnitt.

• Gör det möjligt för WPF-program att köras på ett säkert sätt i flera programdomänscenarier.

• Förhindra obehörig åtkomst till tilläggsgränssnittets fönsterhandtag när tillägg körs med säkerhetsisolering (det vill säga: en delsäkerhetssandlåda). Anrop ViewToContractAdapter garanterar den här säkerheten:

  • För programmeringsmodellen "add-in returns a UI" är det enda sättet att skicka fönsterhandtaget för ett tilläggs-UI över isoleringsgränsen att anropa ViewToContractAdapter.

  • För programmeringsmodellen "add-in is a UI" krävs att åsidosätta QueryContract på adaptern på tilläggssidan och anropa ViewToContractAdapter (som visas i föregående exempel), liksom att anropa implementationskoden för QueryContract i adaptern på värdsidan.

• Tillhandahålla exekveringsskydd för flera programdomäner. På grund av begränsningar med programdomäner orsakar ohanterade undantag som genereras i tilläggsprogramdomäner att hela programmet kraschar, även om isoleringsgränsen finns. WPF och .NET Framework-tilläggsmodellen är dock ett enkelt sätt att kringgå det här problemet och förbättra programstabiliteten. Ett WPF-tillägg som visar ett användargränssnitt skapar en Dispatcher för den tråd som programdomänen körs på, om värdprogrammet är ett WPF-program. Du kan identifiera alla ohanterade undantag som inträffar i programdomänen genom att hantera UnhandledException händelsen för WPF-tilläggets Dispatcher. Du kan hämta Dispatcher från egenskapen CurrentDispatcher .

WPF-Add-In begränsningar

Utöver de fördelar som WPF lägger till standardbeteenden som tillhandahålls av HwndSource, HwndHostoch fönsterhandtag, finns det också begränsningar för tilläggsanvändargränssnitt som visas från värdprogram:

• Tilläggsanvändargränssnitt som visas från ett värdprogram respekterar inte värdprogrammets urklippsbeteende.

• Begreppet luftrum i samverkansscenarier gäller även för tillägg (se Översikt över teknikregioner).

• Ett värdprograms användargränssnittstjänster, till exempel resursarv, databindning och kommandon, är inte automatiskt tillgängliga för tilläggsanvändargränssnitt. Om du vill tillhandahålla dessa tjänster till tillägget måste du uppdatera pipelinen.

• Ett tilläggsgränssnitt kan inte roteras, skalas, skevas eller påverkas på annat sätt av en transformering (se Översikt över transformeringar).

• Innehåll i tilläggsanvändargränssnitt som återges genom ritningsoperationer från System.Drawing namnområdet kan innehålla alfa-blandning. Men både ett tilläggsgränssnitt och värdprogrammets användargränssnitt som innehåller det måste vara 100% ogenomskinliga. Med andra ord måste egenskapen Opacity på båda vara inställd på 1.

• AllowsTransparency Om egenskapen för ett fönster i värdprogrammet som innehåller ett tilläggsgränssnitt har angetts till trueär tillägget osynligt. Detta gäller även om tilläggsgränssnittet är 100% ogenomskinlig (det vill: Opacity egenskapen har värdet 1).

• Ett tilläggsgränssnitt måste visas ovanpå andra WPF-element i samma fönster på den översta nivån.

• Ingen del av ett tilläggs användargränssnitt kan renderas med hjälp av en VisualBrush. I stället kan tillägget ta en ögonblicksbild av det genererade användargränssnittet för att skapa en bitmapp som kan skickas till värdprogrammet med hjälp av metoder som definierats av kontraktet.

• Mediefiler kan inte spelas upp från en MediaElement i ett tilläggsgränssnitt.

• Mushändelser som genereras för tilläggets användargränssnitt tas varken emot eller initieras av värdprogrammet, och egenskapen IsMouseOver för värdprogrammets användargränssnitt har värdet false.

• När fokus ändras mellan kontroller i ett tilläggsgränssnitt, varken GotFocus eller LostFocus-händelser tas emot eller aktiveras av värdprogrammet.

• Den del av ett värdprogram som innehåller ett tilläggsgränssnitt visas som vit när det skrivs ut.

• Alla avsändare (se Dispatcher) som skapats av tilläggets användargränssnitt måste stängas av manuellt innan ägartillägget tas bort om värdprogrammet fortsätter att köras. Kontraktet kan implementera metoder som gör det möjligt för värdprogrammet att signalera tillägget innan tillägget tas bort, vilket gör att tilläggsgränssnittet kan stänga av sina avsändare.

• Om ett tilläggsgränssnitt är ett InkCanvas eller innehåller ett InkCanvaskan du inte ta bort tillägget.

Prestandaoptimering

När flera programdomäner används som standard läses alla de olika .NET Framework-sammansättningar som krävs av varje program in i programmets domän. Därför kan den tid som krävs för att skapa nya programdomäner och starta program i dem påverka prestandan. Med .NET Framework kan du dock minska starttiderna genom att instruera program att dela sammansättningar mellan programdomäner om de redan har lästs in. Du gör detta genom att använda LoaderOptimizationAttribute attributet, som måste tillämpas på startpunktsmetoden (Main). I det här fallet måste du bara använda kod för att implementera programdefinitionen (se Översikt över programhantering).

Se även

• LoaderOptimizationAttribute
• tillägg och utökningsbarhet
• Programdomäner
• Översikt över .NET Framework-fjärrkommunikation
• Göra objekt fjärrkommunikationsbara
• Ämnen om hur man gör