Udostępnij za pośrednictwem

Przegląd Dodatki WPF

  • Artykuł

Program .NET Framework zawiera model dodatku, którego deweloperzy mogą używać do tworzenia aplikacji obsługujących rozszerzalność dodatków. Ten model dodatku umożliwia tworzenie dodatków, które integrują się z i rozszerzają funkcjonalność aplikacji. W niektórych scenariuszach aplikacje muszą również wyświetlać interfejsy użytkownika udostępniane przez dodatki. W tym temacie pokazano, jak platforma WPF rozszerza model dodatków .NET Framework w celu włączenia tych scenariuszy, architektury, jej zalet i ograniczeń.

Wymagania wstępne

Wymagana jest znajomość modelu dodatku .NET Framework. Aby uzyskać więcej informacji, zobacz Dodatki i rozszerzalność.

Omówienie dodatków

Aby uniknąć złożoności ponownej kompilacji i ponownego wdrażania aplikacji w celu uwzględnienia nowych funkcji, aplikacje implementują mechanizmy rozszerzalności, które umożliwiają deweloperom (zarówno firmy pierwszej, jak i innej firmy) tworzenie innych aplikacji, które je integrują. Najczęstszym sposobem obsługi tego typu rozszerzalności jest użycie dodatków (nazywanych również "dodatkami" i "wtyczek"). Przykłady rzeczywistych aplikacji, które uwidaczniają rozszerzalność za pomocą dodatków, to:

  • Dodatki programu Internet Explorer.

  • Odtwarzacz multimedialny Windows wtyczki.

  • Dodatki programu Visual Studio.

Na przykład model dodatku Odtwarzacz multimedialny Windows umożliwia deweloperom innych firm zaimplementowanie "wtyczek", które rozszerzają Odtwarzacz multimedialny Windows na różne sposoby, w tym tworzenie dekoderów i koderów dla formatów multimediów, które nie są obsługiwane natywnie przez Odtwarzacz multimedialny Windows (na przykład DVD, MP3), efekty dźwiękowe i skóry. Każdy model dodatku jest tworzony w celu uwidocznienia funkcji, które są unikatowe dla aplikacji, chociaż istnieje kilka jednostek i zachowań, które są wspólne dla wszystkich modeli dodatków.

Trzy główne jednostki typowych rozwiązań rozszerzalności dodatków to kontrakty, dodatki i aplikacje hosta. Kontrakty definiują sposób integrowania dodatków z aplikacjami hosta na dwa sposoby:

  • Dodatki integrują się z funkcjami implementowanych przez aplikacje hosta.

  • Aplikacje hosta uwidaczniają funkcje dodatków do integracji z.

Aby można było używać dodatków, aplikacje hosta muszą je znaleźć i załadować w czasie wykonywania. W związku z tym aplikacje obsługujące dodatki mają następujące dodatkowe obowiązki:

  • Odnajdywanie: znajdowanie dodatków, które są zgodne z kontraktami obsługiwanymi przez aplikacje hosta.

  • Aktywacja: ładowanie, uruchamianie i nawiązywanie komunikacji z dodatkami.

  • Izolacja: używanie domen aplikacji lub procesów w celu ustanowienia granic izolacji, które chronią aplikacje przed potencjalnymi problemami z zabezpieczeniami i wykonywaniem dodatków.

  • Komunikacja: Umożliwianie dodawaniom i aplikacjom hostów komunikowania się ze sobą przez granice izolacji przez wywoływanie metod i przekazywanie danych.

  • Zarządzanie okresem istnienia: ładowanie i zwalnianie domen aplikacji oraz procesów w przejrzysty, przewidywalny sposób (zobacz Domeny aplikacji).

  • Przechowywanie wersji: zapewnienie, że aplikacje hosta i dodatki mogą nadal komunikować się po utworzeniu nowych wersji.

Ostatecznie opracowanie niezawodnego modelu dodatku jest nietrygalnym przedsięwzięciem. Z tego powodu platforma .NET Framework udostępnia infrastrukturę do tworzenia modeli dodatków.

Uwaga

Aby uzyskać bardziej szczegółowe informacje na temat dodatków, zobacz Dodatki i rozszerzalność.

Omówienie modelu dodatków programu .NET Framework

Model dodatku .NET Framework znaleziony w System.AddIn przestrzeni nazw zawiera zestaw typów zaprojektowanych w celu uproszczenia opracowywania rozszerzeń dodatków. Podstawową jednostką modelu dodatku .NET Framework jest kontrakt, który definiuje sposób, w jaki aplikacja hosta i dodatek komunikują się ze sobą. Kontrakt jest udostępniany aplikacji hosta przy użyciu widoku specyficznego dla aplikacji hosta kontraktu. Podobnie do dodatku jest uwidaczniony widok kontraktu specyficzny dla dodatku. Karta służy do zezwalania aplikacji hosta i dodatku na komunikację między odpowiednimi widokami kontraktu. Kontrakty, widoki i karty są określane jako segmenty, a zestaw powiązanych segmentów stanowi potok. Potoki są podstawą, na której model dodatku .NET Framework obsługuje odnajdywanie, aktywację, izolację zabezpieczeń, izolację wykonywania (przy użyciu domen aplikacji i procesów), komunikację, zarządzanie okresem istnienia i przechowywanie wersji.

Suma tej obsługi umożliwia deweloperom tworzenie dodatków integrujących się z funkcjami aplikacji hosta. Jednak niektóre scenariusze wymagają hostowania aplikacji do wyświetlania interfejsów użytkownika udostępnianych przez dodatki. Ponieważ każda technologia prezentacji w programie .NET Framework ma własny model implementowania interfejsów użytkownika, model dodatku .NET Framework nie obsługuje żadnej konkretnej technologii prezentacji. Zamiast tego WPF rozszerza model dodatków .NET Framework z obsługą interfejsu użytkownika dodatków.

Dodatki WPF

WPF, w połączeniu z modelem dodatków .NET Framework, umożliwia rozwiązanie wielu różnych scenariuszy, które wymagają hostowania aplikacji do wyświetlania interfejsów użytkownika z dodatków. W szczególności te scenariusze są rozwiązywane przez WPF z następującymi dwoma modelami programowania:

  1. Dodatek zwraca interfejs użytkownika. Dodatek zwraca interfejs użytkownika do aplikacji hosta za pośrednictwem wywołania metody, zgodnie z definicją kontraktu. Ten scenariusz jest używany w następujących przypadkach:

    • Wygląd interfejsu użytkownika zwracanego przez dodatek jest zależny od danych lub warunków, które istnieją tylko w czasie wykonywania, takich jak dynamicznie generowane raporty.

    • Interfejs użytkownika usług udostępnianych przez dodatek różni się od interfejsu użytkownika aplikacji hosta, które mogą używać dodatku.

    • Dodatek wykonuje przede wszystkim usługę dla aplikacji hosta i zgłasza stan aplikacji hosta za pomocą interfejsu użytkownika.

  2. Dodatek jest interfejsem użytkownika. Dodatek jest interfejsem użytkownika zdefiniowanym przez kontrakt. Ten scenariusz jest używany w następujących przypadkach:

    • Dodatek nie zapewnia usług innych niż wyświetlane, takich jak anons.

    • Interfejs użytkownika dla usług udostępnianych przez dodatek jest wspólny dla wszystkich aplikacji hosta, które mogą używać tego dodatku, takiego jak kalkulator lub selektor kolorów.

Te scenariusze wymagają przekazania obiektów interfejsu użytkownika między aplikacją hosta a domenami aplikacji dodatków. Ponieważ model dodatku .NET Framework opiera się na komunikacji wirtualnej między domenami aplikacji, obiekty, które są przekazywane między nimi, muszą być remotable.

Obiekt remotable jest wystąpieniem klasy, która wykonuje co najmniej jedną z następujących czynności:

Uwaga

Aby uzyskać więcej informacji na temat tworzenia obiektów programu .NET Framework remotable, zobacz Tworzenie obiektów remotable.

Typy interfejsu użytkownika WPF nie są remotable. Aby rozwiązać ten problem, WPF rozszerza model dodatku .NET Framework w celu włączenia interfejsu użytkownika WPF utworzonego przez dodatki, które mają być wyświetlane z aplikacji hosta. Ta obsługa jest zapewniana przez WPF przez dwa typy: INativeHandleContract interfejs i dwie metody statyczne implementowane przez klasę FrameworkElementAdapters : ContractToViewAdapter i ViewToContractAdapter. Na wysokim poziomie te typy i metody są używane w następujący sposób:

  1. WPF wymaga, aby interfejsy użytkownika udostępniane przez dodatki to klasy, które pochodzą bezpośrednio lub pośrednio z FrameworkElementelementów , takich jak kształty, kontrolki, kontrolki użytkownika, panele układu i strony.

  2. Wszędzie tam, gdzie kontrakt deklaruje, że interfejs użytkownika zostanie przekazany między dodatkiem a aplikacją hosta, musi zostać zadeklarowany jako INativeHandleContract (a nie FrameworkElement); INativeHandleContract jest remotable reprezentacją interfejsu użytkownika dodatku, który może zostać przekazany przez granice izolacji.

  3. Przed przekazaniem z domeny FrameworkElement aplikacji dodatku element jest spakowany jako element INativeHandleContract przez wywołanie metody ViewToContractAdapter.

  4. Po przekazaniu do domeny INativeHandleContract aplikacji hosta element musi zostać ponownie spakowany jako element FrameworkElement przez wywołanie metody ContractToViewAdapter.

Sposób INativeHandleContractużycia , ContractToViewAdapteri ViewToContractAdapter zależy od konkretnego scenariusza. Poniższe sekcje zawierają szczegółowe informacje dotyczące każdego modelu programowania.

Dodatek zwraca interfejs użytkownika

Aby dodatek zwrócił interfejs użytkownika do aplikacji hosta, wymagane są następujące elementy:

  1. Należy utworzyć aplikację hosta, dodatek i potok zgodnie z opisem w dokumentacji dodatków programu .NET Framework i rozszerzalności .

  2. Kontrakt musi zaimplementować IContract i, aby zwrócić interfejs użytkownika, kontrakt musi zadeklarować metodę z zwracaną wartością typu INativeHandleContract.

  3. Interfejs użytkownika przekazywany między dodatkiem a aplikacją hosta musi pochodzić bezpośrednio lub pośrednio z elementu FrameworkElement.

  4. Interfejs użytkownika zwracany przez dodatek musi zostać przekonwertowany z elementu na FrameworkElement element INativeHandleContract przed przekroczeniem granicy izolacji.

  5. Zwrócony interfejs użytkownika musi zostać przekonwertowany z elementu na wartość INativeHandleContractFrameworkElement po przekroczeniu granicy izolacji.

  6. Aplikacja hosta wyświetla zwrócony FrameworkElementelement .

Przykład, który pokazuje, jak zaimplementować dodatek, który zwraca interfejs użytkownika, zobacz Tworzenie dodatku zwracającego interfejs użytkownika.

Dodatek to interfejs użytkownika

Gdy dodatek jest interfejsem użytkownika, wymagane są następujące elementy:

  1. Należy utworzyć aplikację hosta, dodatek i potok zgodnie z opisem w dokumentacji dodatków programu .NET Framework i rozszerzalności .

  2. Interfejs kontraktu dodatku musi implementować INativeHandleContractelement .

  3. Dodatek przekazywany do aplikacji hosta musi bezpośrednio lub pośrednio pochodzić z elementu FrameworkElement.

  4. Dodatek musi zostać przekonwertowany z elementu na FrameworkElement element INativeHandleContract przed przejściem przez granicę izolacji.

  5. Dodatek musi zostać przekonwertowany z elementu INativeHandleContract na po FrameworkElement przekroczeniu granicy izolacji.

  6. Aplikacja hosta wyświetla zwrócony FrameworkElementelement .

Aby zapoznać się z przykładem, który pokazuje, jak zaimplementować dodatek, który jest interfejsem użytkownika, zobacz Tworzenie dodatku, który jest interfejsem użytkownika.

Zwracanie wielu interfejsów użytkownika z dodatku

Dodatki często udostępniają wiele interfejsów użytkownika do wyświetlania aplikacji hosta. Rozważmy na przykład dodatek, który jest interfejsem użytkownika, który udostępnia również informacje o stanie aplikacji hosta, a także jako interfejs użytkownika. Dodatek, taki jak ten, można zaimplementować przy użyciu kombinacji technik zarówno z dodatku zwraca interfejs użytkownika, jak i dodatek jest modelem interfejsu użytkownika.

Dodatki i aplikacje przeglądarki XAML

W przykładach do tej pory aplikacja hosta była zainstalowaną aplikacją autonomiczną. Jednak aplikacje przeglądarki XAML (XBAPs) mogą również hostować dodatki, choć z następującymi dodatkowymi wymaganiami kompilacji i implementacji:

  • Manifest aplikacji XBAP musi być skonfigurowany specjalnie do pobierania potoku (folderów i zestawów) i zestawu dodatków do pamięci podręcznej aplikacji ClickOnce na komputerze klienckim, w tym samym folderze co XBAP.

  • Kod XBAP do odnajdywania i ładowania dodatków musi używać pamięci podręcznej aplikacji ClickOnce dla XBAP jako potoku i lokalizacji dodatku.

  • XBAP musi załadować dodatek do specjalnego kontekstu zabezpieczeń, jeśli dodatek odwołuje się do luźnych plików znajdujących się w miejscu pochodzenia; w przypadku hostowania przez XBAPs dodatki mogą odwoływać się tylko do luźnych plików znajdujących się w witrynie pochodzenia aplikacji hosta.

Te zadania zostały szczegółowo opisane w poniższych podsekcjach.

Konfigurowanie potoku i dodatku dla wdrożenia technologii ClickOnce

XBAPs są pobierane do i uruchamiane z bezpiecznego folderu w pamięci podręcznej wdrażania ClickOnce. Aby program XBAP hostował dodatek, należy również pobrać potok i zestaw dodatków do bezpiecznego folderu. Aby to osiągnąć, należy skonfigurować manifest aplikacji w celu uwzględnienia zarówno potoku, jak i zestawu dodatku do pobrania. Jest to najłatwiejsze w programie Visual Studio, chociaż potok i zestaw dodatków muszą znajdować się w folderze głównym projektu XBAP hosta, aby program Visual Studio wykrywał zestawy potoków.

W związku z tym pierwszym krokiem jest skompilowanie potoku i zestawu dodatku do katalogu głównego projektu XBAP przez ustawienie danych wyjściowych kompilacji każdego zestawu potoku i projektów zestawów dodatków. W poniższej tabeli przedstawiono ścieżki wyjściowe kompilacji dla projektów zestawów potoku i projektu zestawu dodatków, które znajdują się w tym samym rozwiązaniu i folderze głównym co projekt XBAP hosta.

Tabela 1. Tworzenie ścieżek wyjściowych dla zestawów potoków hostowanych przez XBAP

Projekt zestawu potoku Ścieżka danych wyjściowych kompilacji
Kontrakt ..\HostXBAP\Contracts\
Widok dodatku ..\HostXBAP\AddInViews\
Adapter dodatku ..\HostXBAP\AddInSideAdapters\
Adapter po stronie hosta ..\HostXBAP\HostSideAdapters\
Dodatek ..\HostXBAP\AddIns\WPFAddIn1

Następnym krokiem jest określenie zestawów potoków i zestawu dodatku jako plików zawartości XBAPs w programie Visual Studio, wykonując następujące czynności:

  1. Dołączenie potoku i zestawu dodatku w projekcie przez kliknięcie prawym przyciskiem myszy każdego folderu potoku w Eksplorator rozwiązań i wybranie pozycji Uwzględnij w projekcie.

  2. Ustawianie akcji kompilacji każdego zestawu potoku i zestawu dodatku do zawartości w oknie Właściwości.

Ostatnim krokiem jest skonfigurowanie manifestu aplikacji w celu uwzględnienia plików zestawu potoku i pliku zestawu dodatku do pobrania. Pliki powinny znajdować się w folderach w folderze głównym folderu w pamięci podręcznej ClickOnce zajmowanej przez aplikację XBAP. Konfigurację można osiągnąć w programie Visual Studio, wykonując następujące czynności:

  1. Kliknij prawym przyciskiem myszy projekt XBAP, kliknij polecenie Właściwości, kliknij pozycję Publikuj, a następnie kliknij przycisk Pliki aplikacji.

  2. W oknie dialogowym Pliki aplikacji ustaw stan publikowania każdego potoku i biblioteki DLL dodatku na wartość Include (Auto), a następnie ustaw grupępobierania dla każdego potoku i dodatek DLL na wartość (Wymagane).

Używanie potoku i dodatku z bazy aplikacji

Po skonfigurowaniu potoku i dodatku do wdrożenia technologii ClickOnce są pobierane do tego samego folderu pamięci podręcznej ClickOnce co XBAP. Aby użyć potoku i dodatku z XBAP, kod XBAP musi pobrać je z bazy aplikacji. Różne typy i elementy członkowskie modelu dodatku .NET Framework do korzystania z potoków i dodatków zapewniają specjalną obsługę tego scenariusza. Po pierwsze, ścieżka jest identyfikowana przez ApplicationBase wartość wyliczenia. Ta wartość jest używana z przeciążeniami odpowiednich elementów członkowskich dodatku do korzystania z potoków, które obejmują następujące elementy:

Uzyskiwanie dostępu do witryny hosta źródła

Aby upewnić się, że dodatek może odwoływać się do plików z lokacji pochodzenia, dodatek musi zostać załadowany z izolacją zabezpieczeń, która jest odpowiednikiem aplikacji hosta. Ten poziom zabezpieczeń jest identyfikowany przez AddInSecurityLevel.Host wartość wyliczenia i przekazywany do Activate metody po aktywowaniu dodatku.

Architektura dodatków WPF

Na najwyższym poziomie, jak widzieliśmy, WPF umożliwia dodatekom .NET Framework implementowanie interfejsów użytkownika (które pochodzą bezpośrednio lub pośrednio z FrameworkElementprogramu ) przy użyciu poleceń INativeHandleContracti ViewToContractAdapter .ContractToViewAdapter Wynikiem jest zwrócenie aplikacji hosta wyświetlanej FrameworkElement z interfejsu użytkownika w aplikacji hosta.

W przypadku prostych scenariuszy dodawania interfejsu użytkownika jest to tyle szczegółów, ile potrzebuje deweloper. W przypadku bardziej złożonych scenariuszy, szczególnie tych, które próbują korzystać z dodatkowych usług WPF, takich jak układ, zasoby i powiązanie danych, bardziej szczegółowa wiedza na temat rozszerzania modelu dodatku .NET Framework z obsługą interfejsu użytkownika jest wymagana, aby zrozumieć jego zalety i ograniczenia.

Zasadniczo platforma WPF nie przekazuje interfejsu użytkownika z dodatku do aplikacji hosta; Zamiast tego WPF przekazuje dojście okna Win32 dla interfejsu użytkownika przy użyciu współdziałania WPF. W związku z tym, gdy interfejs użytkownika z dodatku zostanie przekazany do aplikacji hosta, wystąpią następujące czynności:

  • Po stronie dodatku WPF uzyskuje uchwyt okna dla interfejsu użytkownika, który będzie wyświetlany przez aplikację hosta. Uchwyt okna jest hermetyzowany przez wewnętrzną klasę WPF, która pochodzi z HwndSource klasy i implementuje INativeHandleContractelement . Wystąpienie tej klasy jest zwracane przez ViewToContractAdapter klasę i jest marshalowane z domeny aplikacji dodatku do domeny aplikacji hosta.

  • Po stronie aplikacji hosta platforma WPF ponownie pakuje HwndSource element jako wewnętrzną klasę WPF, która pochodzi z HwndHost klasy i korzysta z klasy INativeHandleContract. Wystąpienie tej klasy jest zwracane przez ContractToViewAdapter aplikację hosta.

HwndHost istnieje, aby wyświetlić interfejsy użytkownika, identyfikowane przez uchwyty okien, z interfejsów użytkownika WPF. Aby uzyskać więcej informacji, zobacz WPF i Win32 Interoperation (Współdziałanie w systemach WPF i Win32).

Podsumowując, INativeHandleContract, ViewToContractAdapteri ContractToViewAdapter istnieje, aby umożliwić dojście okna interfejsu użytkownika WPF do aplikacji hosta, gdzie jest hermetyzowany przez HwndHost interfejs użytkownika aplikacji hosta i wyświetlać interfejs użytkownika aplikacji hosta.

Uwaga

Ponieważ aplikacja hosta pobiera HwndHostelement , aplikacja hosta nie może przekonwertować obiektu zwróconego przez ContractToViewAdapter element na typ, który jest implementowany przez dodatek (na przykład UserControl).

Ze względu na jego charakter HwndHost , ma pewne ograniczenia, które wpływają na sposób, w jaki aplikacje hostów mogą ich używać. Jednak WPF rozszerza się HwndHost o kilka możliwości w scenariuszach dodatków. Te korzyści i ograniczenia zostały opisane poniżej.

Korzyści dodatku WPF

Ponieważ interfejsy użytkownika dodatku WPF są wyświetlane z aplikacji hosta przy użyciu klasy wewnętrznej pochodzącej z HwndHostklasy , te interfejsy użytkownika są ograniczone przez możliwości HwndHost usług interfejsu użytkownika WPF, takich jak układ, renderowanie, powiązanie danych, style, szablony i zasoby. Jednak platforma WPF rozszerza wewnętrzną HwndHost podklasę o dodatkowe możliwości, które obejmują następujące elementy:

  • Tabulatory między interfejsem użytkownika aplikacji hosta a interfejsem użytkownika dodatku. Należy pamiętać, że model programowania "dodatek jest interfejsem użytkownika" wymaga, aby karta dodatku została zastąpiona QueryContract w celu włączenia tabulacji, niezależnie od tego, czy dodatek jest w pełni zaufany, czy częściowo zaufany.

  • Spełnianie wymagań dotyczących ułatwień dostępu dla interfejsów użytkownika dodatków wyświetlanych z interfejsów użytkownika aplikacji hosta.

  • Włączenie aplikacji WPF do bezpiecznego uruchamiania w wielu scenariuszach domeny aplikacji.

  • Zapobieganie nielegalnemu dostępowi do uchwytów okien interfejsu użytkownika dodatków podczas uruchamiania dodatków z izolacją zabezpieczeń (czyli piaskownicy zabezpieczeń częściowego zaufania). Wywołanie ViewToContractAdapter zapewnia następujące zabezpieczenia:

    • W przypadku modelu programowania "dodatek zwraca interfejs użytkownika" jedynym sposobem przekazania dojścia okna dla interfejsu użytkownika dodatku w granicach izolacji jest wywołanie metody ViewToContractAdapter.

    • W przypadku modelu programowania "dodatek jest interfejsem użytkownika", zastępowanie QueryContract karty dodatku i wywoływanie ViewToContractAdapter (jak pokazano w poprzednich przykładach) jest wymagane, podobnie jak wywoływanie implementacji adaptera dodatku z karty QueryContract po stronie hosta.

  • Zapewnianie ochrony wykonywania wielu domen aplikacji. Ze względu na ograniczenia dotyczące domen aplikacji nieobsługiwane wyjątki zgłaszane w domenach aplikacji dodatków powodują awarię całej aplikacji, mimo że istnieje granica izolacji. Jednak WPF i model dodatków .NET Framework zapewniają prosty sposób obejścia tego problemu i poprawy stabilności aplikacji. Dodatek WPF, który wyświetla interfejs użytkownika tworzy Dispatcher element dla wątku, w ramach którego działa domena aplikacji, jeśli aplikacja hosta jest aplikacją WPF. Można wykryć wszystkie nieobsługiwane wyjątki występujące w domenie aplikacji, obsługując UnhandledException zdarzenie dodatku DispatcherWPF . Obiekt można pobrać Dispatcher z CurrentDispatcher właściwości .

Ograniczenia dodatku WPF

Poza korzyściami, które WPF dodaje do domyślnych zachowań dostarczonych przez HwndSourcedojścia , HwndHosti okna, istnieją również ograniczenia dotyczące interfejsów użytkownika dodatków wyświetlanych z aplikacji hosta:

  • Interfejsy użytkownika dodatku wyświetlane z aplikacji hosta nie są zgodne z zachowaniem przycinania aplikacji hosta.

  • Pojęcie przestrzeni powietrznej w scenariuszach współdziałania dotyczy również dodatków (zobacz Omówienie regionów technologii).

  • Usługi interfejsu użytkownika aplikacji hosta, takie jak dziedziczenie zasobów, powiązanie danych i polecenia, nie są automatycznie dostępne dla interfejsów użytkownika dodatku. Aby udostępnić te usługi do dodatku, należy zaktualizować potok.

  • Interfejs użytkownika dodatku nie może być obracany, skalowany, niesymetryczny lub w inny sposób dotknięty transformacją (zobacz Omówienie przekształceń).

  • Zawartość wewnątrz interfejsów użytkownika dodatku renderowanych przez operacje rysowania z System.Drawing przestrzeni nazw może obejmować mieszanie alfa. Jednak zarówno interfejs użytkownika dodatku, jak i interfejs użytkownika aplikacji hosta, który go zawiera, musi mieć 100% nieprzezroczyste; innymi słowy, Opacity właściwość na obu musi być ustawiona na 1.

  • AllowsTransparency Jeśli właściwość okna w aplikacji hosta, która zawiera interfejs użytkownika dodatku, jest ustawiona na truewartość , dodatek jest niewidoczny. Jest to prawdą, nawet jeśli interfejs użytkownika dodatku ma 100% nieprzezroczyste (czyli Opacity właściwość ma wartość 1).

  • Interfejs użytkownika dodatku musi pojawić się w górnej części innych elementów WPF w tym samym oknie najwyższego poziomu.

  • Nie można renderować żadnej części interfejsu użytkownika dodatku przy użyciu elementu VisualBrush. Zamiast tego dodatek może utworzyć migawkę wygenerowanego interfejsu użytkownika, aby utworzyć mapę bitową, którą można przekazać do aplikacji hosta przy użyciu metod zdefiniowanych przez kontrakt.

  • Nie można odtwarzać plików multimedialnych z poziomu interfejsu MediaElement użytkownika dodatku.

  • Zdarzenia myszy generowane dla interfejsu użytkownika dodatku nie są odbierane ani zgłaszane przez aplikację hosta, a IsMouseOver właściwość interfejsu użytkownika aplikacji hosta ma wartość false.

  • Gdy fokus przesuwa się między kontrolkami w interfejsie użytkownika dodatku, GotFocus zdarzenia i LostFocus nie są ani odbierane, ani zgłaszane przez aplikację hosta.

  • Część aplikacji hosta, która zawiera interfejs użytkownika dodatku, jest wyświetlana w kolorze białym po wydrukowaniu.

  • Wszystkie dyspozytorów (zobacz Dispatcher) utworzone przez interfejs użytkownika dodatku muszą zostać zamknięte ręcznie, zanim dodatek właściciela zostanie zwolniony, jeśli aplikacja hosta będzie kontynuować wykonywanie. Kontrakt może implementować metody, które umożliwiają aplikacji hosta sygnalizowanie dodatku przed zwolnieniem dodatku, dzięki czemu interfejs użytkownika dodatku może zamknąć dyspozytorów.

  • Jeśli interfejs użytkownika dodatku jest elementem InkCanvas lub zawiera element InkCanvas, nie można zwolnić dodatku.

Optymalizacja wydajności

Domyślnie w przypadku użycia wielu domen aplikacji różne zestawy programu .NET Framework wymagane przez każdą aplikację są ładowane do domeny tej aplikacji. W związku z tym czas wymagany do tworzenia nowych domen aplikacji i uruchamiania w nich aplikacji może mieć wpływ na wydajność. Jednak program .NET Framework umożliwia skrócenie czasu rozpoczęcia, nakazując aplikacjom udostępnianie zestawów między domenami aplikacji, jeśli zostały już załadowane. W tym celu należy użyć atrybutu LoaderOptimizationAttribute , który należy zastosować do metody punktu wejścia (Main). W takim przypadku należy użyć tylko kodu, aby zaimplementować definicję aplikacji (zobacz Omówienie zarządzania aplikacjami).

Zobacz też