Condividi tramite

Panoramica di WPF Add-Ins

.NET Framework include un modello di componente aggiuntivo che gli sviluppatori possono usare per creare applicazioni che supportano l'estendibilità dei componenti aggiuntivi. Questo modello di componente aggiuntivo consente la creazione di componenti aggiuntivi che si integrano con ed estendono la funzionalità dell'applicazione. In alcuni scenari, le applicazioni devono anche visualizzare le interfacce utente fornite dai componenti aggiuntivi. Questo argomento illustra in che modo WPF aumenta il modello di componente aggiuntivo .NET Framework per abilitare questi scenari, l'architettura sottostante, i relativi vantaggi e le relative limitazioni.

Prerequisiti

È necessaria la familiarità con il modello di componente aggiuntivo .NET Framework. Per altre informazioni, vedere Componenti aggiuntivi ed estendibilità.

Panoramica di Add-Ins

Per evitare le complessità della ricompilazione e della ridistribuzione delle applicazioni per incorporare nuove funzionalità, le applicazioni implementano meccanismi di estendibilità che consentono agli sviluppatori (sia proprietari che di terze parti) di creare altre applicazioni che si integrano con esse. Il modo più comune per supportare questo tipo di estendibilità consiste nell'usare i componenti aggiuntivi (noti anche come "componenti aggiuntivi" e "plug-in"). Esempi di applicazioni reali che espongono estendibilità con componenti aggiuntivi includono:

  • Componenti aggiuntivi di Internet Explorer.

  • Plug-in di Windows Media Player.

  • Componenti aggiuntivi di Visual Studio.

Ad esempio, il modello di componente aggiuntivo windows Media Player consente agli sviluppatori di terze parti di implementare "plug-in" che estendono Windows Media Player in diversi modi, tra cui la creazione di decodificatori e codificatori per formati multimediali non supportati in modo nativo da Windows Media Player (ad esempio DVD, MP3), effetti audio e interfacce. Ogni modello di componente aggiuntivo viene creato per esporre le funzionalità univoche di un'applicazione, anche se esistono diverse entità e comportamenti comuni a tutti i modelli di componente aggiuntivo.

Le tre entità principali delle tipiche soluzioni di estendibilità dei componenti aggiuntivi sono contratti, componenti aggiuntivi e applicazioni host. I contratti definiscono il modo in cui i componenti aggiuntivi si integrano con le applicazioni host in due modi:

  • I componenti aggiuntivi si integrano con le funzionalità implementate dalle applicazioni host.

  • Le applicazioni host espongono funzionalità per l'integrazione dei componenti aggiuntivi.

Per poter usare i componenti aggiuntivi, le applicazioni host devono trovarle e caricarle in fase di esecuzione. Di conseguenza, le applicazioni che supportano i componenti aggiuntivi hanno le responsabilità aggiuntive seguenti:

  • Scoperta: ricerca di componenti aggiuntivi conformi ai contratti supportati dalle applicazioni host.

  • Attivazione: caricamento, esecuzione e comunicazione con i componenti aggiuntivi.

  • Isolamento: uso di domini applicazione o processi per stabilire limiti di isolamento che proteggono le applicazioni da potenziali problemi di sicurezza ed esecuzione con i componenti aggiuntivi.

  • Comunicazione: consente ai componenti aggiuntivi e alle applicazioni host di comunicare tra loro attraverso i limiti di isolamento chiamando metodi e passando i dati.

  • Gestione della durata: caricamento e scaricamento di domini e processi dell'applicazione in modo pulito e prevedibile (vedere Domini applicazione).

  • Controllo delle versioni: verifica che le applicazioni host e i componenti aggiuntivi possano comunque comunicare quando vengono create nuove versioni di una di queste.

In definitiva, lo sviluppo di un modello di componente aggiuntivo affidabile è un'impresa non semplice. Per questo motivo, .NET Framework fornisce un'infrastruttura per la creazione di modelli di componente aggiuntivo.

Annotazioni

Per informazioni più dettagliate sui componenti aggiuntivi, vedere Componenti aggiuntivi ed estendibilità.

Panoramica del Modello Add-In .NET Framework

Il modello di add-in del .NET Framework, nello spazio dei nomi System.AddIn, contiene un set di tipi progettati per semplificare lo sviluppo dell'estendibilità degli add-in. L'unità fondamentale del modello di componente aggiuntivo .NET Framework è il contratto, che definisce il modo in cui un'applicazione host e un componente aggiuntivo comunicano tra loro. Un contratto viene esposto a un'applicazione host utilizzando una visualizzazione specifica per l'applicazione host del contratto. Analogamente, una visualizzazione del contratto specifica per il componente aggiuntivo viene esposta al componente aggiuntivo. Un adattatore viene usato per consentire a un'applicazione host e a un componente aggiuntivo di comunicare tra le rispettive visualizzazioni del contratto. I contratti, le visualizzazioni e gli adattatori vengono definiti segmenti e un set di segmenti correlati costituisce una pipeline. Le pipeline sono la base su cui il modello di componente aggiuntivo .NET Framework supporta l'individuazione, l'attivazione, l'isolamento della sicurezza, l'isolamento dell'esecuzione (usando sia domini applicazione che processi), la comunicazione, la gestione della durata e il controllo delle versioni.

La somma di questo supporto consente agli sviluppatori di creare componenti aggiuntivi che si integrano con la funzionalità di un'applicazione host. Tuttavia, alcuni scenari richiedono che le applicazioni host visualizzino le interfacce utente fornite dai componenti aggiuntivi. Poiché ogni tecnologia di presentazione in .NET Framework ha un proprio modello per l'implementazione delle interfacce utente, il modello di componente aggiuntivo .NET Framework non supporta alcuna tecnologia di presentazione specifica. WPF estende invece il modello di componente aggiuntivo .NET Framework con il supporto dell'interfaccia utente per i componenti aggiuntivi.

Add-Ins WPF

WPF, in combinazione con il modello di componente aggiuntivo .NET Framework, consente di gestire un'ampia gamma di scenari che richiedono alle applicazioni host di visualizzare le interfacce utente dai componenti aggiuntivi. In particolare, questi scenari vengono gestiti da WPF con i due modelli di programmazione seguenti:

  1. Il componente aggiuntivo restituisce un'interfaccia utente. Un componente aggiuntivo restituisce un'interfaccia utente all'applicazione host tramite una chiamata al metodo, come definito dal contratto. Questo scenario viene usato nei casi seguenti:

    • L'aspetto di un'interfaccia utente restituita da un componente aggiuntivo dipende da dati o condizioni esistenti solo in fase di esecuzione, ad esempio report generati dinamicamente.

    • L'interfaccia utente per i servizi forniti da un componente aggiuntivo è diversa dall'interfaccia utente delle applicazioni host che possono usare il componente aggiuntivo.

    • Il componente aggiuntivo esegue principalmente un servizio per l'applicazione host e segnala lo stato all'applicazione host con un'interfaccia utente.

  2. Il componente aggiuntivo è un'interfaccia utente. Un componente aggiuntivo è un'interfaccia utente, come definito dal contratto. Questo scenario viene usato nei casi seguenti:

    • Un componente aggiuntivo non fornisce servizi diversi dalla visualizzazione, ad esempio un annuncio pubblicitario.

    • L'interfaccia utente per i servizi forniti da un componente aggiuntivo è comune a tutte le applicazioni host che possono usare tale componente aggiuntivo, ad esempio una calcolatrice o una selezione colori.

Questi scenari richiedono che gli oggetti dell'interfaccia utente possano essere passati tra l'applicazione host e i domini applicazione del componente aggiuntivo. Poiché il modello di componente aggiuntivo .NET Framework si basa sulla comunicazione remota per comunicare tra domini applicazione, gli oggetti passati tra di essi devono essere remotizzabili.

Un oggetto remotable è un'istanza di una classe che esegue una o più delle operazioni seguenti:

Annotazioni

Per altre informazioni sulla creazione di oggetti .NET Framework remotabili, vedere Creazione di oggetti remotizzabili.

I tipi di interfaccia utente WPF non sono remotizzabili. Per risolvere il problema, WPF estende il modello di componente aggiuntivo .NET Framework per consentire la visualizzazione dell'interfaccia utente WPF creata dai componenti aggiuntivi dalle applicazioni host. Questo supporto viene fornito da WPF da due tipi: l'interfaccia INativeHandleContract e due metodi statici implementati dalla FrameworkElementAdapters classe : ContractToViewAdapter e ViewToContractAdapter. A livello generale, questi tipi e metodi vengono usati nel modo seguente:

  1. WPF richiede che le interfacce utente fornite dai componenti aggiuntivi siano classi che derivano direttamente o indirettamente da FrameworkElement, ad esempio forme, controlli, controlli utente, pannelli di layout e pagine.

  2. Ovunque il contratto dichiari che un'interfaccia utente verrà passata tra il componente aggiuntivo e l'applicazione host, essa deve essere dichiarata come un INativeHandleContract (non un FrameworkElement); INativeHandleContract è una rappresentazione remota dell'interfaccia utente del componente aggiuntivo che può essere passata attraverso i limiti di isolamento.

  3. Prima di essere trasferito dal dominio dell'applicazione del componente aggiuntivo, un FrameworkElement viene confezionato come INativeHandleContract chiamando ViewToContractAdapter.

  4. Dopo essere stato passato al dominio applicazione dell'applicazione host, l'oggetto INativeHandleContract deve essere ripacchetto come oggetto FrameworkElement chiamando ContractToViewAdapter.

Il modo in cui vengono utilizzati INativeHandleContract, ContractToViewAdapter e ViewToContractAdapter dipende dallo scenario specifico. Le sezioni seguenti forniscono informazioni dettagliate per ogni modello di programmazione.

Add-In restituisce un'interfaccia utente

Affinché un componente aggiuntivo restituisca un'interfaccia utente a un'applicazione host, sono necessari gli elementi seguenti:

  1. È necessario creare l'applicazione host, il componente aggiuntivo e la pipeline, come descritto dalla documentazione relativa ai componenti aggiuntivi e all'estendibilità di .NET Framework.

  2. Il contratto deve implementare IContract e, per restituire un'interfaccia utente, il contratto deve dichiarare un metodo con un valore restituito di tipo INativeHandleContract.

  3. L'interfaccia utente passata tra il componente aggiuntivo e l'applicazione host deve derivare direttamente o indirettamente da FrameworkElement.

  4. L'interfaccia utente restituita dal componente aggiuntivo deve essere convertita da un FrameworkElement a un INativeHandleContract prima di attraversare il limite di isolamento.

  5. L'interfaccia utente restituita deve essere convertita da un INativeHandleContract a un FrameworkElement dopo aver superato il limite di isolamento.

  6. L'applicazione host visualizza l'oggetto restituito FrameworkElement.

Per un esempio che illustra come implementare un componente aggiuntivo che restituisce un'interfaccia utente, vedere Creare un Add-In che restituisce un'interfaccia utente.

Add-In è un'interfaccia utente

Quando un componente aggiuntivo è un'interfaccia utente, sono necessari gli elementi seguenti:

  1. È necessario creare l'applicazione host, il componente aggiuntivo e la pipeline, come descritto dalla documentazione relativa ai componenti aggiuntivi e all'estendibilità di .NET Framework.

  2. L'interfaccia del contratto per il componente aggiuntivo deve implementare INativeHandleContract.

  3. Il componente aggiuntivo passato all'applicazione host deve derivare direttamente o indirettamente da FrameworkElement.

  4. Il componente aggiuntivo deve essere convertito da un FrameworkElement a un INativeHandleContract prima di superare il limite di isolamento.

  5. Il componente aggiuntivo deve essere convertito da un INativeHandleContract oggetto a un FrameworkElement dopo aver superato il limite di isolamento.

  6. L'applicazione host visualizza l'oggetto restituito FrameworkElement.

Per un esempio che illustra come implementare un componente aggiuntivo che è un'interfaccia utente, vedere Creare un Add-In che è un'interfaccia utente.

Restituzione di diverse interfacce utente da un Add-In

I componenti aggiuntivi spesso forniscono più interfacce utente per la visualizzazione delle applicazioni host. Si consideri ad esempio un componente aggiuntivo che è un'interfaccia utente che fornisce anche informazioni sullo stato per l'applicazione host, anche come interfaccia utente. Un componente aggiuntivo simile a questo può essere implementato usando una combinazione di tecniche diAdd-In restituisce un'interfaccia utente e Add-In è un modello di interfaccia utente .

Add-Ins e applicazioni browser XAML

Negli esempi finora l'applicazione host è stata un'applicazione autonoma installata. Tuttavia, le applicazioni browser XAML (XBAP) possono anche ospitare componenti aggiuntivi, anche se con i requisiti di compilazione e implementazione aggiuntivi seguenti:

  • Il manifesto dell'applicazione XBAP deve essere configurato appositamente per scaricare la pipeline (cartelle e assembly) e l'assembly del componente aggiuntivo nella cache dell'applicazione ClickOnce nel computer client, nella stessa cartella di XBAP.

  • Il codice XBAP per individuare e caricare i componenti aggiuntivi deve usare la cache dell'applicazione ClickOnce per XBAP come pipeline e percorso del componente aggiuntivo.

  • XBAP deve caricare il componente aggiuntivo in un contesto di sicurezza speciale se il componente aggiuntivo fa riferimento a file separati che si trovano nel sito di origine; se ospitato da XBAP, i componenti aggiuntivi possono fare riferimento solo a file separati che si trovano nel sito di origine dell'applicazione host.

Queste attività sono descritte in dettaglio nelle sottosezioni seguenti.

Configurazione della pipeline e Add-In per la distribuzione di ClickOnce

I file XBAP vengono scaricati ed eseguiti da una cartella sicura nella cache di distribuzione ClickOnce. Affinché un XBAP ospiti un componente aggiuntivo, è necessario scaricare anche la pipeline e l'assembly del componente aggiuntivo nella cartella sicura. Per raggiungere questo obiettivo, è necessario configurare il manifesto dell'applicazione in modo da includere sia la pipeline sia l'assembly del componente aggiuntivo per il download. Questa operazione viene eseguita più facilmente in Visual Studio, anche se la pipeline e l'assembly del componente aggiuntivo devono trovarsi nella cartella radice del progetto XBAP host per consentire a Visual Studio di rilevare gli assembly della pipeline.

Di conseguenza, il primo passaggio consiste nel costruire la pipeline e l'assembly del componente aggiuntivo nella directory principale del progetto XBAP configurando l'output di compilazione di ciascun progetto di assembly della pipeline e del componente aggiuntivo. La tabella seguente illustra i percorsi di output della compilazione per i progetti di assembliaggio della pipeline e dei componenti aggiuntivi che si trovano nella stessa soluzione e cartella radice del progetto XBAP host.

Tabella 1: Definire i percorsi di output per gli assembly della pipeline ospitati in un XBAP

Progetto di assemblaggio della pipeline Percorso di output della compilazione
Contratto ..\HostXBAP\Contracts\
visualizzazione Add-In ..\HostXBAP\AddInViews\
Aggiungi-In-Side Adattatore ..\HostXBAP\AddInSideAdapters\
Adattatore Host-Side ..\HostXBAP\HostSideAdapters\
Add-In ..\HostXBAP\AddIns\WPFAddIn1

Il passaggio successivo consiste nel specificare gli assembly della pipeline e l'assembly del componente aggiuntivo come file di contenuto XBAP in Visual Studio eseguendo le operazioni seguenti:

  1. Includere la pipeline e l'assembly del componente aggiuntivo nel progetto facendo clic con il pulsante destro del mouse su ogni cartella della pipeline in Esplora soluzioni e scegliendo Includi in progetto.

  2. Imposta l'azione di compilazione di ciascun assembly della pipeline e dell'assembly del componente aggiuntivo in Contenuto dalla finestra Proprietà.

Il passaggio finale consiste nel configurare il manifesto dell'applicazione in modo da includere i file di assembly della pipeline e il file di assembly del componente aggiuntivo per il download. I file devono trovarsi in cartelle nella radice della cartella nella cache ClickOnce occupata dall'applicazione XBAP. La configurazione può essere ottenuta in Visual Studio eseguendo le operazioni seguenti:

  1. Fare clic con il pulsante destro del mouse sul progetto XBAP, fare clic Proprietà, fare clic Pubblica e quindi fare clic sul pulsante File applicazione.

  2. Nella finestra di dialogo File dell'applicazione impostare il Stato pubblicazione di ogni pipeline e DLL del componente aggiuntivo su Includi (auto), e impostare il Gruppo di download per ogni pipeline e DLL del componente aggiuntivo su (obbligatorio).

Utilizzo della Pipeline e Add-In dalla struttura di base dell'applicazione

Quando la pipeline e il componente aggiuntivo sono configurati per la distribuzione ClickOnce, vengono scaricati nella stessa cartella della cache ClickOnce di XBAP. Per usare la pipeline e il componente aggiuntivo da XBAP, il codice XBAP deve recuperarli dalla base dell'applicazione. I vari tipi e membri del modello di componente aggiuntivo .NET Framework per l'uso di pipeline e componenti aggiuntivi offrono un supporto speciale per questo scenario. In primo luogo, il percorso viene identificato dal valore di enumerazione ApplicationBase. Questo valore viene usato con gli overload dei membri del componente aggiuntivo pertinenti per l'uso di pipeline che includono quanto segue:

Accesso al sito di origine dell'host

Per assicurarsi che un componente aggiuntivo possa fare riferimento ai file dal sito di origine, il componente aggiuntivo deve essere caricato con isolamento di sicurezza equivalente all'applicazione host. Questo livello di sicurezza viene identificato dal valore di AddInSecurityLevel.Host enumerazione e passato al Activate metodo quando viene attivato un componente aggiuntivo.

Architettura WPF Add-In

Al livello più alto, come si è visto, WPF consente ai componenti aggiuntivi .NET Framework di implementare interfacce utente (che derivano direttamente o indirettamente da FrameworkElement) usando INativeHandleContracte ViewToContractAdapterContractToViewAdapter. Il risultato è che viene restituito all'applicazione host un oggetto FrameworkElement, visualizzato dall'interfaccia utente nell'applicazione host.

Per semplici scenari di add-in dell'interfaccia utente, questi sono tutti i dettagli di cui un sviluppatore ha bisogno. Per scenari più complessi, in particolare quelli che tentano di usare servizi WPF aggiuntivi, ad esempio layout, risorse e data binding, è necessaria una conoscenza più dettagliata del modo in cui WPF estende il modello di componente aggiuntivo .NET Framework con il supporto dell'interfaccia utente per comprendere i vantaggi e le limitazioni.

Fondamentalmente, WPF non passa un'interfaccia utente da un componente aggiuntivo a un'applicazione host; WPF passa invece l'handle della finestra Win32 per l'interfaccia utente usando l'interoperabilità WPF. Di conseguenza, quando un'interfaccia utente da un componente aggiuntivo viene passata a un'applicazione host, si verifica quanto segue:

  • Dal lato del componente aggiuntivo, WPF acquisisce un handle di finestra per l'interfaccia utente che verrà visibile dall'applicazione host. La maniglia della finestra è racchiusa da una classe WPF interna che deriva da HwndSource e implementa INativeHandleContract. Un'istanza di questa classe viene restituita da ViewToContractAdapter e viene trasferita dal dominio dell'applicazione del componente aggiuntivo al dominio dell'applicazione host.

  • Sull'applicazione host, WPF riconfeziona HwndSource come classe interna WPF che deriva da HwndHost e utilizza INativeHandleContract. Un'istanza di questa classe viene restituita da ContractToViewAdapter all'applicazione host.

HwndHost esiste per visualizzare le interfacce utente, identificate dagli handle di finestra, dalle interfacce utente WPF. Per altre informazioni, vedere Interoperabilità WPF e Win32.

In sintesi, INativeHandleContract, ViewToContractAdapter e ContractToViewAdapter esistono per consentire il passaggio dell'handle di finestra per un'interfaccia utente WPF da un componente aggiuntivo a un'applicazione host, in cui è incapsulato da HwndHost e mostrato nell'interfaccia utente dell'applicazione host.

Annotazioni

Poiché l'applicazione host riceve un HwndHost, non può convertire l'oggetto restituito da ContractToViewAdapter nel tipo in cui è implementato dal componente aggiuntivo (ad esempio un UserControl).

Per natura, HwndHost presenta alcune limitazioni che influiscono sul modo in cui le applicazioni host possono usarle. Tuttavia, WPF si estende HwndHost con diverse funzionalità per gli scenari di componenti aggiuntivi. Questi vantaggi e limitazioni sono descritti di seguito.

WPF Add-In Vantaggi

Poiché le interfacce utente dei componenti aggiuntivi WPF vengono visualizzate dalle applicazioni host usando una classe interna che deriva da HwndHost, tali interfacce utente sono vincolate dalle funzionalità di HwndHost rispetto ai servizi dell'interfaccia utente WPF, ad esempio layout, rendering, data binding, stili, modelli e risorse. Wpf, tuttavia, aumenta la sottoclasse interna HwndHost con funzionalità aggiuntive che includono quanto segue:

  • Navigazione tra l'interfaccia utente di un'applicazione host e l'interfaccia utente di un componente aggiuntivo. Si noti che il modello di programmazione per cui "il componente aggiuntivo è un'interfaccia utente" richiede che l'adattatore sul lato del componente aggiuntivo esegua l'override di QueryContract per abilitare la tabulazione, a prescindere dal fatto che il componente aggiuntivo sia completamente o parzialmente attendibile.

  • Rispettare i requisiti di accessibilità per le interfacce utente del componente aggiuntivo visualizzate dalle interfacce utente dell'applicazione host.

  • Abilitazione dell'esecuzione sicura delle applicazioni WPF in più scenari di dominio applicazione.

  • Impedire l'accesso illegale agli handle della finestra dell'interfaccia utente del componente aggiuntivo quando i componenti aggiuntivi vengono eseguiti con isolamento della sicurezza, cioè in una sandbox di sicurezza parzialmente attendibile. La chiamata ViewToContractAdapter garantisce questa sicurezza:

    • Per il modello di programmazione "add-in restituisce un'interfaccia utente", l'unico modo per passare l'handle della finestra per un'interfaccia utente del componente aggiuntivo attraverso il limite di isolamento consiste nel chiamare ViewToContractAdapter.

    • Per il modello di programmazione "componente aggiuntivo è un'interfaccia utente", è necessario eseguire l'override QueryContract sull'adattatore lato componente aggiuntivo e chiamare ViewToContractAdapter (come illustrato negli esempi precedenti), così come chiamare l'implementazione dell'adattatore QueryContract dall'adattatore sul lato host.

  • Protezione dell'esecuzione di più domini dell'applicazione. A causa delle limitazioni con i domini applicativi, le eccezioni non gestite generate nei domini applicativi del componente aggiuntivo provocano il crash dell'intera applicazione, anche se esiste il limite di isolamento. Tuttavia, WPF e il modello di componente aggiuntivo .NET Framework offrono un modo semplice per risolvere questo problema e migliorare la stabilità dell'applicazione. Un componente aggiuntivo WPF che visualizza un'interfaccia utente crea un Dispatcher per il thread su cui è in esecuzione il dominio applicativo, se l'applicazione host è un'applicazione WPF. È possibile rilevare tutte le eccezioni non gestite che si verificano nel dominio dell'applicazione gestendo l'evento UnhandledException del Dispatchercomponente aggiuntivo WPF . È possibile ottenere il Dispatcher dalla proprietà CurrentDispatcher.

WPF Add-In Limitazioni

Oltre ai vantaggi che WPF aggiunge ai comportamenti predefiniti forniti da HwndSource, HwndHost e dagli handle di finestra, esistono anche limitazioni per le interfacce utente del componente aggiuntivo visualizzate dalle applicazioni host.

  • Le interfacce utente dell'add-in visualizzate da un'applicazione host non rispettano il comportamento di ritaglio dell'applicazione host.

  • Il concetto di spazio aereo negli scenari di interoperabilità si applica anche ai componenti aggiuntivi (vedere Panoramica delle aree tecnologiche).

  • I servizi dell'interfaccia utente di un'applicazione host, ad esempio l'ereditarietà delle risorse, il data binding e il comando, non sono automaticamente disponibili per le interfacce utente dei componenti aggiuntivi. Per fornire questi servizi al componente aggiuntivo, è necessario aggiornare la pipeline.

  • Un'interfaccia utente del componente aggiuntivo non può essere ruotata, ridimensionata, asimmetrica o interessata da una trasformazione (vedere Cenni preliminari sulle trasformazioni).

  • Il contenuto all'interno delle interfacce utente del componente aggiuntivo, reso attraverso operazioni di disegno nell'ambito del System.Drawing namespace, può includere la trasparenza alfa. Tuttavia, sia un'interfaccia utente del componente aggiuntivo che l'interfaccia utente dell'applicazione host che lo contiene devono essere 100% opache; in altre parole, la Opacity proprietà su entrambi deve essere impostata su 1.

  • Se la AllowsTransparency proprietà di una finestra nell'applicazione host che contiene un'interfaccia utente del componente aggiuntivo è impostata su true, il componente aggiuntivo è invisibile. Questo vale anche se l'interfaccia utente del componente aggiuntivo è 100% opaca , ovvero la Opacity proprietà ha un valore pari a 1.

  • Un'interfaccia utente del componente aggiuntivo deve essere visualizzata sopra altri elementi WPF nella stessa finestra di primo livello.

  • Non è possibile eseguire il rendering di alcuna parte dell'interfaccia utente di un componente aggiuntivo usando un oggetto VisualBrush. Al contrario, il componente aggiuntivo può creare uno snapshot dell'interfaccia utente generata per creare una bitmap che può essere passata all'applicazione host usando metodi definiti dal contratto.

  • I file multimediali non possono essere riprodotti da un MediaElement oggetto in un'interfaccia utente del componente aggiuntivo.

  • Gli eventi del mouse generati dall'interfaccia utente del componente aggiuntivo non vengono né ricevuti né attivati dall'applicazione host, e la proprietà dell'interfaccia IsMouseOver utente dell'applicazione host ha il valore false.

  • Quando lo stato attivo si sposta tra i controlli in un'interfaccia utente del componente aggiuntivo, gli eventi GotFocus e LostFocus non vengono né ricevuti né generati dall'applicazione host.

  • La parte di un'applicazione host che contiene un'interfaccia utente del componente aggiuntivo appare bianca quando viene stampata.

  • Tutti i dispatcher (vedere Dispatcher) creati dall'interfaccia utente del componente aggiuntivo devono essere arrestati manualmente prima che il componente aggiuntivo proprietario venga scaricato se l'applicazione host continua l'esecuzione. Il contratto può implementare metodi che consentono all'applicazione host di segnalare il componente aggiuntivo prima che il componente aggiuntivo venga scaricato, consentendo così all'interfaccia utente del componente aggiuntivo di arrestare i dispatcher.

  • Se l'interfaccia utente di un componente aggiuntivo è un InkCanvas o contiene un InkCanvas, non è possibile disattivare il componente aggiuntivo.

Ottimizzazione delle prestazioni

Per impostazione predefinita, quando vengono usati più domini applicazione, i vari assembly .NET Framework richiesti da ogni applicazione vengono tutti caricati nel dominio dell'applicazione. Di conseguenza, il tempo necessario per la creazione di nuovi domini applicazione e l'avvio di applicazioni in essi potrebbero influire sulle prestazioni. Tuttavia, .NET Framework consente di ridurre i tempi di avvio indicando alle applicazioni di condividere assembly tra domini applicazione se sono già caricati. A tale scopo, usare l'attributo LoaderOptimizationAttribute , che deve essere applicato al metodo del punto di ingresso (Main). In questo caso, è necessario usare solo il codice per implementare la definizione dell'applicazione (vedere Panoramica sulla gestione delle applicazioni).

Vedere anche

  • Last updated on