Udostępnij za pośrednictwem

Omówienie WPF Add-Ins

  • Artykuł

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

Warunki wstępne

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

Add-Ins Omówienie

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.

  • Wtyczki programu Windows Media Player.

  • Dodatki programu Visual Studio.

Na przykład model dodatku Windows Media Player umożliwia deweloperom innych firm implementowanie "wtyczek", które rozszerzają program Windows Media Player 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 program Windows Media Player (na przykład DVD, MP3), efekty dźwiękowe i skórki. 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 elementy 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 udostępniają funkcjonalności do integracji z dodatkami.

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:

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

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

  • izolacja: Używanie domen aplikacji lub procesów do ustanawiania granic izolacji, które chronią aplikacje przed potencjalnymi problemami z zabezpieczeniami i wykonywaniem dodatków.

  • Communication: umożliwianie dodatkom i aplikacjom hosta komunikacji między sobą przez granice izolacji, poprzez 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).

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

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

Notatka

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

Omówienie modelu Add-In programu .NET Framework

Model dodatku .NET Framework znajdujący się w przestrzeni nazw System.AddIn 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 za pomocą widoku specyficznego dla aplikacji hosta kontraktu. Podobnie, widok kontraktu specyficzny dla dodatku jest udostępniany dla dodatku. Adapter jest używany do umożliwienia aplikacji hosta i dodatku komunikacji między ich odpowiednimi widokami kontraktu. Kontrakty, widoki i adaptery 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 cyklem życia oraz wersjonowanie.

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, zapewniając wsparcie dla interfejsów użytkownika.

WPF Add-Ins

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 UI. 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ż bycie wyświetlanym, takich jak reklama.

    • 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 zdalnym wywoływaniu do komunikacji między domenami aplikacji, obiekty, które są przekazywane między nimi, muszą być zdalnie wywoływane.

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

Notatka

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

Typy interfejsu użytkownika WPF nie są remotable. Aby rozwiązać ten problem, WPF rozszerza model dodatku .NET Framework, aby umożliwić wyświetlanie interfejsu użytkownika WPF utworzonego przez dodatki z aplikacji hosta. Ta obsługa jest zapewniana przez WPF przez dwa typy: interfejs INativeHandleContract 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 FrameworkElement, takich jak kształty, kontrolki, kontrolki użytkownika, panele układu i strony.

  2. Gdziekolwiek kontrakt deklaruje, że interfejs użytkownika jest przekazywany między dodatkiem a aplikacją hosta, musi zostać zadeklarowany jako INativeHandleContract (a nie FrameworkElement); INativeHandleContract to zdalna reprezentacja interfejsu użytkownika dodatku, którą można przekazać przez granice izolacyjne.

  3. Zanim zostanie przekazane z domeny aplikacji dodatku, FrameworkElement jest pakowane jako INativeHandleContract poprzez wywołanie ViewToContractAdapter.

  4. Po przekazaniu do domeny aplikacji hosta, należy ponownie spakować INativeHandleContract jako FrameworkElement przez wywołanie ContractToViewAdapter.

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

Add-In 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 .NET Framework Add-ins and Extensibility.

  2. Kontrakt musi implementować IContract i, aby zadeklarować metodę zwracającą interfejs użytkownika, kontrakt musi mieć wartość zwracaną typu INativeHandleContract.

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

  4. Interfejs użytkownika zwracany przez dodatek musi zostać przekonwertowany z FrameworkElement na INativeHandleContract przed przejściem przez granicę izolacji.

  5. Zwrócony interfejs użytkownika musi zostać przekonwertowany z INativeHandleContract na FrameworkElement po przekroczeniu granicy izolacji.

  6. Aplikacja hostingowa wyświetla zwrócony FrameworkElement.

Aby zapoznać się z przykładem implementacji dodatku zwracającego interfejs użytkownika, zobacz sekcję Utwórz Add-In, który zwraca interfejs użytkownika.

Add-In jest interfejsem 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 dotyczącej dodatków i rozszerzalności .NET Framework i.

  2. Interfejs kontraktu dodatku musi implementować INativeHandleContract.

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

  4. Dodatek musi zostać przekonwertowany z FrameworkElement na INativeHandleContract przed przekroczeniem granicy izolacji.

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

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

Aby zapoznać się z przykładem, jak zaimplementować dodatek będący interfejsem użytkownika, zobacz Create an Add-In That Is a UI.

Zwracanie wielu interfejsów użytkownika z Add-In

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ć, używając kombinacji technik z modeli zarówno Add-In Zwracania interfejsu użytkownika, jak i Add-In Będącego interfejsem użytkownika.

Add-Ins i aplikacje przeglądarkowe 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 w sposób umożliwiający pobranie potoku (folderów i zestawów) oraz zestawu dodatku 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 korzystać z pamięci podręcznej aplikacji ClickOnce dla XBAP, pełniąc rolę zarówno potoku, jak 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 Pipeline i Add-In dla wdrożenia 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 dodatku i jego zestaw do bezpiecznego folderu. Aby to osiągnąć, należy skonfigurować manifest aplikacji, aby uwzględniał do pobrania zarówno potok, jak i zestaw dodatku. 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 zbudowanie potoku i zestawu dodatku w katalogu głównym projektu XBAP poprzez ustawienie wyników kompilacji dla każdego projektu zestawu potoku i projektu zestawu dodatku. W poniższej tabeli przedstawiono ścieżki wyjściowe kompilacji dla projektów zestawów potoków oraz projektu zestawu dodatku, które znajdują się w tym samym rozwiązaniu i folderze głównym co projekt główny XBAP.

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

Projekt montażu rurociągu Ścieżka wyjściowa kompilacji
Kontrakt ..\HostXBAP\Contracts\
widok Add-In ..\HostXBAP\AddInViews\
Dodaj adapterIn-Side ..\HostXBAP\AddInSideAdapters\
Adapter Host-Side ..\HostXBAP\HostSideAdapters\
Add-In ..\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 Eksploratorze rozwiązań i wybranie uwzględnij w projekcie.

  2. Ustawienie akcji kompilacji każdego zestawu potoku i zestawu dodatku w celu 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 głównym katalogu pamięci podręcznej ClickOnce, który zajmuje aplikacja 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 Właściwości, kliknij Publikuj, a następnie kliknij Pliki aplikacji.

  2. W oknie dialogowym plików aplikacji ustaw stan publikowania dla każdego potoku i biblioteki DLL dodatku w celu dołączania (automatycznie)i ustaw pobieranie grupy dla każdego potoku i dodatku DLL na (wymagane).

Używanie potoku i Add-In z bazy aplikacji

Gdy potok i dodatek są skonfigurowane do wdrożenia przez ClickOnce, pobierane są 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 członkowie modelu dodatku .NET Framework dla korzystania z potoków i dodatków zapewniają specjalną obsługę tego scenariusza. Po pierwsze, ścieżka jest identyfikowana przez wartość wyliczenia ApplicationBase. 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 wartość wyliczenia AddInSecurityLevel.Host i przekazywany do metody Activate po aktywowaniu dodatku.

Architektura Add-In WPF

Na najwyższym poziomie, jak widzieliśmy, WPF umożliwia dodatki .NET Framework do implementowania interfejsów użytkownika (które pochodzą bezpośrednio lub pośrednio z FrameworkElement) przy użyciu INativeHandleContract, ViewToContractAdapter i ContractToViewAdapter. Wynikiem jest, że aplikacja hosta otrzymuje FrameworkElement, która jest wyświetlana przez interfejs 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 i implementuje INativeHandleContract. Instancja tej klasy jest zwracana przez ViewToContractAdapter i jest przekazywana z domeny aplikacji dodatku do domeny aplikacji hosta.

  • Po stronie aplikacji hosta platforma WPF ponownie pakuje HwndSource jako wewnętrzną klasę WPF pochodzącą z HwndHost i zużywa INativeHandleContract. Wystąpienie tej klasy jest zwracane przez ContractToViewAdapter do aplikacji hostującej.

HwndHost służy do wyświetlania interfejsów użytkownika, które są identyfikowane przez uchwyty okien z interfejsów użytkownika WPF. Aby uzyskać więcej informacji, zobacz WPF i Win32 Interoperation.

pl-PL: Podsumowując, INativeHandleContract, ViewToContractAdapteri ContractToViewAdapter istnieją, aby umożliwić przekazywanie uchwytu okna dla interfejsu użytkownika WPF z dodatku do aplikacji hosta, gdzie jest on hermetyzowany przez HwndHost i wyświetlany w interfejsie użytkownika aplikacji hosta.

Notatka

Ponieważ aplikacja hosta otrzymuje HwndHost, aplikacja hosta nie może przekonwertować obiektu zwróconego przez ContractToViewAdapter na typ, który został zaimplementowany przez dodatek (na przykład UserControl).

Z tego względu HwndHost ma pewne ograniczenia wpływające na sposób korzystania z nich przez aplikacje hosta. Jednak WPF rozszerza HwndHost o dodatkowe możliwości dla scenariuszy dodatków. Te korzyści i ograniczenia zostały opisane poniżej.

Korzyści WPF Add-In

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

  • Przemieszczanie się za pomocą klawisza Tab 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 adapter dodatku przesłonił 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.

  • Umożliwienie bezpiecznego uruchamiania aplikacji WPF w wielu scenariuszach z domenami aplikacji.

  • Zapobieganie nielegalnemu dostępowi do uchwytów okien interfejsu użytkownika dodatków podczas uruchamiania dodatków z izolacją zabezpieczeń, czyli piaskownica zabezpieczeń o częściowym zaufaniu. 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 przez granicę izolacji jest wywołanie ViewToContractAdapter.

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

  • Zapewnianie ochrony dla 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 dla wątku, w ramach którego działa domena aplikacji, jeśli aplikacja hosta jest aplikacją WPF. Wszystkie nieobsługiwane wyjątki występujące w domenie aplikacji można wykryć, obsługując zdarzenie UnhandledException w dodatku WPF Dispatcher. Możesz pobrać Dispatcher za pomocą właściwości CurrentDispatcher.

Ograniczenia WPF Add-In

Poza korzyściami, które WPF dodaje do domyślnych zachowań dostarczonych przez HwndSource, HwndHosti dojścia okien, istnieją również ograniczenia dotyczące interfejsów użytkownika dodatków, które są wyświetlane przez aplikacje hostujące.

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

  • Pojęcie przestrzeni powietrznej w scenariuszach interoperacyjności dotyczy również dodatków (zobacz Technology Regions Overview).

  • Usługi interfejsu użytkownika aplikacji hosta, takie jak dziedziczenie zasobów, powiązanie danych i wydawanie poleceń, nie są automatycznie dostępne dla interfejsów użytkownika wtyczki. Aby udostępnić te usługi dla 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 Transforms Overview).

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

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

  • Interfejs użytkownika dodatku musi pojawić się na wierzchu innych elementów WPF w tym samym oknie najwyższego poziomu.

  • Żadna część interfejsu użytkownika dodatku nie może być renderowana przy użyciu 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.

  • Plików multimedialnych nie można odtworzyć z MediaElement w interfejsie użytkownika dodatku.

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

  • Gdy fokus przesuwa się między kontrolkami w interfejsie użytkownika dodatku, zdarzenia GotFocus i LostFocus nie są 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 dyspozytory (zobacz Dispatcher) utworzone za pomocą interfejsu użytkownika dodatku muszą zostać zamknięte ręcznie, zanim dodatek do aplikacji zostanie zwolniony, jeśli aplikacja główna będzie kontynuować działanie. Kontrakt może implementować metody, które umożliwiają aplikacji hosta sygnalizowanie dodatku, zanim dodatek zostanie odciążony, aby UI dodatku mógł wyłączyć swoich dyspozytorów.

  • Jeśli interfejs użytkownika dodatku jest InkCanvas lub zawiera InkCanvas, nie można odinstalować 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ż