Cenni preliminari sui componenti aggiuntivi di WPF
.NET Framework include un modello di componente aggiuntivo utilizzabile dagli sviluppatori per creare applicazioni che supportano l'estensibilità mediante componenti aggiuntivi. Questo modello consente di creare componenti aggiuntivi che integrano ed estendono le funzionalità dell'applicazione. In alcuni scenari, le applicazioni devono anche visualizzare le UIs fornite dai componenti aggiuntivi. In questo argomento viene illustrato come WPF integra il modello di componente aggiuntivo .NET Framework per consentire i suddetti scenari, oltre all'architettura di base, i vantaggi e le limitazioni.
Nel presente argomento sono contenute le seguenti sezioni.
- Prerequisiti
- Cenni preliminari sui componenti aggiuntivi
- Cenni preliminari sul modello di componente aggiuntivo .NET Framework
- Componenti aggiuntivi WPF
- Componente aggiuntivo che restituisce un'interfaccia utente
- Componente aggiuntivo che rappresenta un'interfaccia utente
- Restituzione di più interfacce utente da un componente aggiuntivo
- Componenti aggiuntivi e applicazioni browser XAML
- Architettura dei componenti aggiuntivi WPF
- Vantaggi dei componenti aggiuntivi WPF
- Limitazioni dei componenti aggiuntivi WPF
- Ottimizzazione delle prestazioni
- Argomenti correlati
Prerequisiti
È richiesta una buona conoscenza del modello di componente aggiuntivo .NET Framework. Per ulteriori informazioni, vedere Componenti aggiuntivi ed estensibilità.
Cenni preliminari sui componenti aggiuntivi
Al fine di evitare le complessità dovute alla ricompilazione e ridistribuzione di un'applicazione per incorporare nuove funzionalità, le applicazioni implementano meccanismi di estensibilità che consentono agli sviluppatori del produttore e di terze parti di creare altre applicazioni di integrazione. Il metodo più comune per supportare questo tipo di estensibilità consiste nell'utilizzo di componenti aggiuntivi, noti anche come "plug-in". Di seguito vengono riportati alcuni esempi di applicazioni reali che espongono l'estensibilità mediante componenti aggiuntivi:
Componenti aggiuntivi Internet Explorer
Plug-in Windows Media Player
Componenti aggiuntivi Visual Studio
Il modello di componente aggiuntivo Windows Media Player, ad esempio, consente agli sviluppatori di terze parti di implementare "plug-in" che estendono Windows Media Player in diversi modi, incluso creando decodificatori e codificatori per formati multimediali non supportati a livello nativo da Windows Media Player (ad esempio DVD, MP3), effetti audio e interfacce. Ogni modello di componente aggiuntivo viene compilato per esporre le funzionalità univoche di un'applicazione, benché vi siano diverse entità e comportamenti comuni a tutti i modelli.
Le tre entità principali delle soluzioni tipiche di estensibilità mediante componenti aggiuntivi sono contratti, componenti aggiuntivi e applicazioni host. I contratti definiscono la modalità di integrazione dei componenti aggiuntivi con le applicazioni host in due modi:
I componenti aggiuntivi vengono integrati con le funzionalità implementate dalle applicazioni host.
Le applicazioni host espongono le funzionalità con cui i componenti aggiuntivi vengono integrati.
Per poter utilizzare i componenti aggiuntivi, occorre che questi vengano individuati e caricati dalle applicazioni host in fase di esecuzione. Di conseguenza, le applicazioni che supportano i componenti aggiuntivi sono responsabili di quanto segue:
Individuazione, ovvero cercare i componenti aggiuntivi conformi ai contratti supportati dalle applicazioni host.
Attivazione, ovvero caricare, eseguire e stabilire la comunicazione con i componenti aggiuntivi.
Isolamento, ovvero utilizzare i processi o domini dell'applicazione per stabilire i limiti di isolamento che proteggono le applicazioni da potenziali problemi di sicurezza e di esecuzione dovuti ai componenti aggiuntivi.
Comunicazione, ovvero consentire ai componenti aggiuntivi di comunicare con le applicazioni host oltre i limiti di isolamento, mediante la chiamata a metodi e il passaggio di dati.
Gestione della durata, ovvero caricare e scaricare processi e domini dell'applicazione in modo netto e prevedibile; vedere in proposito Domini applicazione.
Controllo delle versioni, ovvero accertare che le applicazioni host e i componenti aggiuntivi possano ancora comunicare successivamente alla creazione di nuove versioni.
Come si evince, lo sviluppo di un modello di componente aggiuntivo affidabile è un'operazione per nulla semplice. Per questo motivo .NET Framework fornisce un'infrastruttura per la compilazione di modelli di componente aggiuntivo.
.gif "Nota") Nota |
|---|
Per informazioni più dettagliate sui componenti aggiuntivi, vedere Componenti aggiuntivi ed estensibilità. |
Cenni preliminari sul modello di componente aggiuntivo .NET Framework
Il modello di componente aggiuntivo .NET Framework, situato nello spazio dei nomi System.AddIn, contiene un set di tipi progettati per semplificare lo sviluppo dell'estensibilità mediante componenti aggiuntivi. L'unità fondamentale del modello di componente aggiuntivo .NET Framework è il contratto, il quale definisce la modalità di comunicazione tra applicazione host e componente aggiuntivo. Un contratto viene esposto a un'applicazione host utilizzando un'apposita visualizzazione specifica dell'applicazione. Analogamente, una visualizzazione del contratto specifica del componente aggiuntivo viene esposta a tale componente. Un adattatore viene utilizzato per consentire la comunicazione tra le rispettive visualizzazioni del contratto. Contratti, visualizzazioni e adattatori sono definiti segmenti; un insieme di segmenti correlati costituisce una pipeline. Le pipeline sono le basi di supporto del modello di componente aggiuntivo .NET Framework per l'individuazione, l'attivazione, l'isolamento di sicurezza, l'isolamento di esecuzione tramite processi e domini dell'applicazione, la comunicazione, la gestione della durata e il controllo delle versioni.
L'intero supporto consente agli sviluppatori di compilare componenti aggiuntivi che vengono integrati con le funzionalità di un'applicazione host. In alcuni scenari, tuttavia, le applicazioni host devono visualizzare le UIs fornite dai componenti aggiuntivi. Dal momento che ogni tecnologia di presentazione in .NET Framework dispone di un proprio modello di implementazione delle UIs, il modello di componente aggiuntivo .NET Framework non supporta alcuna tecnologia in particolare. WPF estende invece il modello di componente aggiuntivo .NET Framework con il supporto dell'UI per i componenti aggiuntivi.
Componenti aggiuntivi WPF
WPF, insieme con il modello di componente aggiuntivo .NET Framework, consente di gestire un'ampia varietà di scenari che richiedono la visualizzazione di UIs da componenti aggiuntivi da parte delle applicazioni host. In particolare, questi scenari vengono gestiti da WPF con i due modelli di programmazione che seguono:
Componente aggiuntivo che restituisce un'interfaccia utente. Un componente aggiuntivo restituisce un'UI all'applicazione host tramite una chiamata al metodo, come definito dal contratto. Questo scenario viene utilizzato nei seguenti casi:
L'aspetto di un'UI restituita da un componente aggiuntivo dipende da dati o condizioni esistenti solo in fase di esecuzione, ad esempio i report generati in modo dinamico.
L'UI per i servizi fornita da un componente aggiuntivo è diversa dall'UI delle applicazioni host che possono utilizzare tale componente.
Il componente aggiuntivo esegue principalmente un servizio per l'applicazione host e segnala lo stato all'applicazione con un'UI.
Componente aggiuntivo che rappresenta un'interfaccia utente. Un componente aggiuntivo rappresenta un'UI, come definito dal contratto. Questo scenario viene utilizzato nei seguenti casi:
Un componente aggiuntivo non fornisce alcun servizio eccetto la visualizzazione, come ad esempio un annuncio.
L'UI per i servizi fornita da un componente aggiuntivo è comune a tutte le applicazioni host che possono utilizzare tale componente, ad esempio una calcolatrice o una finestra Selezione colori.
Questi scenari richiedono che gli oggetti dell'UI possano essere passati tra i domini dell'applicazione del componente aggiuntivo e dell'applicazione host. Poiché il modello di componente aggiuntivo .NET Framework si basa sulla comunicazione remota tra domini dell'applicazione, gli oggetti passati devono essere utilizzabili in modalità remota.
Un oggetto utilizzabile in modalità remota è un'istanza di una classe che soddisfa una o più delle condizioni che seguono:
Deriva dalla classe MarshalByRefObject.
Implementa l'interfaccia ISerializable.
All'istanza viene applicato l'attributo SerializableAttribute.
| Nota |
|---|
Per ulteriori informazioni sulla creazione di oggetti .NET Framework utilizzabili in modalità remota, vedere Making Objects Remotable. |
I tipi di UI WPF non sono utilizzabili in modalità remota. Per risolvere il problema, WPF estende il modello di componente aggiuntivo .NET Framework per consentire la visualizzazione da applicazioni host dell'UI WPF creata dai componenti aggiuntivi. WPF fornisce questo supporto mediante due tipi: l'interfaccia INativeHandleContract e due metodi statici implementati dalla classe FrameworkElementAdapters, ovvero ContractToViewAdapter e ViewToContractAdapter. A un livello elevato, questi tipi e metodi vengono utilizzati nel modo seguente:
WPF richiede che le UIs fornite dai componenti aggiuntivi siano classi derivanti direttamente o indirettamente da FrameworkElement, ad esempio forme, controlli, controlli utente, pannelli di layout e pagine.
Quando il contratto dichiara che un'interfaccia utente verrà passata tra il componente aggiuntivo e l'applicazione host, tale contratto deve essere dichiarato come INativeHandleContract e non come FrameworkElement; INativeHandleContract è una rappresentazione utilizzabile in modalità remota dell'UI del componente aggiuntivo che può essere passata oltre i limiti di isolamento.
Prima di essere passato dal dominio dell'applicazione del componente aggiuntivo, FrameworkElement viene assemblato sotto forma di INativeHandleContract mediante una chiamata a ViewToContractAdapter.
Una volta passato al dominio dell'applicazione host, INativeHandleContract deve essere nuovamente assemblato come FrameworkElement mediante una chiamata a ContractToViewAdapter.
Le modalità di utilizzo di INativeHandleContract, ContractToViewAdapter e ViewToContractAdapter dipendono dallo scenario specifico. Nelle sezioni riportate di seguito vengono forniti i dettagli per ogni modello di programmazione.
Componente aggiuntivo che restituisce un'interfaccia utente
Per fare in modo che un componente aggiuntivo restituisca un'UI a un'applicazione host, è necessario quanto segue:
L'applicazione host, il componente aggiuntivo e la pipeline devono essere creati, come descritto nella documentazione Componenti aggiuntivi ed estensibilità di .NET Framework.
Il contratto deve implementare IContract e, per restituire un'UI, deve dichiarare un metodo con un valore restituito di tipo INativeHandleContract.
L'UI passata tra il componente aggiuntivo e l'applicazione host deve derivare direttamente o indirettamente da FrameworkElement.
L'UI restituita dal componente aggiuntivo deve essere convertita da FrameworkElement a INativeHandleContract prima di oltrepassare il limite di isolamento.
L'UI restituita deve essere convertita da INativeHandleContract a FrameworkElement dopo aver oltrepassato il limite di isolamento.
L'applicazione host visualizza l'oggetto FrameworkElement restituito.
Per un esempio che dimostra come implementare un componente aggiuntivo che restituisce un'UI, vedere Procedura: creare un componente aggiuntivo che restituisce un'interfaccia utente.
Componente aggiuntivo che rappresenta un'interfaccia utente
Quando un componente aggiuntivo rappresenta un'UI, è necessario quanto segue:
L'applicazione host, il componente aggiuntivo e la pipeline devono essere creati, come descritto nella documentazione Componenti aggiuntivi ed estensibilità di .NET Framework.
L'interfaccia del contratto per il componente aggiuntivo deve implementare INativeHandleContract.
Il componente aggiuntivo passato all'applicazione host deve derivare direttamente o indirettamente da FrameworkElement.
Il componente aggiuntivo deve essere convertito da FrameworkElement a INativeHandleContract prima di oltrepassare il limite di isolamento.
Il componente aggiuntivo deve essere convertito da INativeHandleContract a FrameworkElement dopo aver oltrepassato il limite di isolamento.
L'applicazione host visualizza l'oggetto FrameworkElement restituito.
Per un esempio che dimostra come implementare un componente aggiuntivo che costituisce un'UI, vedere Procedura: creare un componente aggiuntivo che costituisce un'interfaccia utente.
Restituzione di più interfacce utente da un componente aggiuntivo
Nei componenti aggiuntivi sono spesso disponibili più UIs per la visualizzazione di applicazioni host. Si consideri ad esempio un componente aggiuntivo che rappresenta un'UI e fornisce anche informazioni sullo stato all'applicazione host, sempre sotto forma di UI. Un componente aggiuntivo di questo tipo può essere implementato utilizzando una combinazione di tecniche afferenti ai modelli Componente aggiuntivo che restituisce un'interfaccia utente e Componente aggiuntivo che rappresenta un'interfaccia utente.
Componenti aggiuntivi e applicazioni browser XAML
Negli esempi illustrati finora l'applicazione host era un'applicazione autonoma installata. Anche le XAML browser applications (XBAPs), però, possono ospitare componenti aggiuntivi, sebbene con i requisiti di compilazione e implementazione aggiuntivi che seguono:
Il manifesto dell'applicazione XBAP deve essere appositamente configurato per scaricare la pipeline (cartelle e assembly) e l'assembly del componente aggiuntivo nella cache dell'applicazione ClickOnce sul computer client, nella stessa cartella dell'applicazione XBAP.
Il codice XBAP che consente di individuare e caricare i componenti aggiuntivi deve utilizzare la cache dell'applicazione ClickOnce per l'applicazione XBAP come percorso della pipeline e dei componenti aggiuntivi.
L'applicazione XBAP deve caricare il componente aggiuntivo in un contesto di sicurezza speciale se tale componente fa riferimento a file separati situati nel sito di origine; se ospitati da applicazioni XBAPs, i componenti aggiuntivi possono fare riferimento unicamente a file separati che si trovano nel sito di origine dell'applicazione host.
Queste attività vengono descritte in dettaglio nelle sottosezioni riportate di seguito.
Configurazione della pipeline e del componente aggiuntivo per la distribuzione ClickOnce
Le applicazioni XBAPs vengono scaricate in una cartella sicura nella cache di distribuzione ClickOnce e da questa eseguite. Affinché un'applicazione XBAP ospiti un componente aggiuntivo, anche l'assembly della pipeline e del componente deve essere scaricato nella cartella sicura. A tal proposito, è necessario configurare il manifesto dell'applicazione per includere l'assembly della pipeline e del componente aggiuntivo per il download. L'operazione risulta più semplice in Visual Studio, anche se l'assembly della pipeline e del componente aggiuntivo deve trovarsi nella cartella radice del progetto di applicazione XBAP affinché Visual Studio rilevi gli assembly della pipeline.
Di conseguenza, il primo passaggio consiste nel compilare l'assembly della pipeline e del componente aggiuntivo nella radice del progetto di applicazione XBAP impostando l'output di compilazione di ogni progetto di assembly della pipeline e del componente aggiuntivo. Nella tabella seguente vengono illustrati i percorsi dell'output di compilazione per i progetti di assembly della pipeline e del componente aggiuntivo che si trovano nella stessa soluzione e cartella radice del progetto di applicazione XBAP host.
Tabella 1: Percorsi dell'output di compilazione per gli assembly della pipeline ospitati da un'applicazione XBAP
Progetto di assembly della pipeline |
Percorso dell'output di compilazione |
|---|---|
Contratto |
.. \HostXBAP\Contracts\ |
Visualizzazione del componente aggiuntivo |
.. \HostXBAP\AddInViews\ |
Adattatore sul lato componente aggiuntivo |
.. \HostXBAP\AddInSideAdapters\ |
Adattatore sul lato host |
.. \HostXBAP\HostSideAdapters\ |
Componente aggiuntivo |
.. \HostXBAP\AddIns\WPFAddIn1 |
Il passaggio successivo consiste nello specificare gli assembly della pipeline e l'assembly del componente aggiuntivo come file di dati delle applicazioni XBAPs in Visual Studio, attenendosi alla procedura riportata di seguito:
Includere l'assembly della pipeline e del componente aggiuntivo nel progetto facendo clic con il pulsante destro del mouse su ogni cartella della pipeline in Esplora soluzioni e scegliendo Includi nel progetto.
Nella finestra Proprietà, impostare l'Operazione di compilazione di ogni assembly della pipeline e del componente aggiuntivo su Contenuto.
Il passaggio finale consiste nel configurare il manifesto dell'applicazione per includere i file di assembly della pipeline e il file di assembly del componente aggiuntivo per il download. I file devono trovarsi all'interno di cartelle nella radice della cartella contenuta nella cache ClickOnce occupata dall'applicazione XBAP. La configurazione può essere effettuata in Visual Studio attenendosi alla procedura che segue:
Fare clic con il pulsante destro del mouse sul progetto di applicazione XBAP, scegliere Proprietà, Pubblica, quindi fare clic sul pulsante File applicazione.
Nella finestra di dialogo File applicazione, impostare lo Stato pubblicazione di ogni DLL della pipeline e del componente aggiuntivo su Includi (Auto), quindi impostare il Gruppo di download per ogni DLL della pipeline e del componente aggiuntivo su (Obbligatorio).
Utilizzo della pipeline e del componente aggiuntivo dalla base dell'applicazione
Quando la pipeline e il componente aggiuntivo sono configurati per la distribuzione ClickOnce, vengono scaricati nella stessa cartella della cache ClickOnce in cui si trova l'applicazione XBAP. Per utilizzare la pipeline e il componente aggiuntivo dall'applicazione XBAP, è necessario che il codice XBAP li ottenga dalla base dell'applicazione. I diversi tipi e membri del modello di componente aggiuntivo .NET Framework per l'utilizzo di pipeline e componenti aggiuntivi forniscono uno speciale supporto per questo scenario. Innanzitutto, il percorso viene identificato dal valore di enumerazione ApplicationBase. Questo valore viene utilizzato con gli overload dei membri del componente aggiuntivo relativi all'utilizzo delle pipeline, che includono quanto segue:
Accesso al sito di origine host
Per assicurare che un componente aggiuntivo possa fare riferimento ai file del sito di origine, tale componente deve essere caricato con lo stesso isolamento di sicurezza dell'applicazione host. Questo livello di sicurezza viene identificato dal valore di enumerazione AddInSecurityLevel.Host e passato al metodo Activate in fase di attivazione di un componente aggiuntivo.
Architettura dei componenti aggiuntivi WPF
Al livello più elevato, come illustrato in precedenza, WPF consente ai componenti aggiuntivi .NET Framework di implementare le UIs, derivanti direttamente o indirettamente da FrameworkElement, utilizzando INativeHandleContract, ViewToContractAdapter e ContractToViewAdapter. Di conseguenza, l'applicazione host restituisce un oggetto FrameworkElement visualizzato dall'UI nell'applicazione stessa.
Nel caso di scenari semplici di componente aggiuntivo dell'UI, gli sviluppatori non necessitano di ulteriori dettagli. Nel caso di scenari più complessi, e in particolare quando si tenta di utilizzare servizi WPF aggiuntivi quali layout, risorse e associazione dati, sarà necessaria una conoscenza più dettagliata del modo in cui WPF estende il modello di componente aggiuntivo .NET Framework con il supporto dell'UI, al fine di comprenderne i vantaggi e le limitazioni.
Fondamentalmente, WPF non passa un'UI da un componente aggiuntivo a un'applicazione host; al contrario, WPF passa l'handle della finestra Win32 per l'UI utilizzando l'interoperabilità WPF. Di conseguenza, quando un'UI viene passata da un componente aggiuntivo a un'applicazione host, si verifica quanto segue:
Sul lato del componente aggiuntivo, WPF acquisisce un handle della finestra per l'UI che verrà visualizzata dall'applicazione host. L'handle della finestra viene incapsulato da una classe WPF interna che deriva da HwndSource e implementa INativeHandleContract. Un'istanza di questa classe viene restituita da ViewToContractAdapter e sottoposta a marshalling dal dominio dell'applicazione del componente aggiuntivo al dominio dell'applicazione host.
Sul lato dell'applicazione host, WPF assembla nuovamente HwndSource come classe WPF interna che deriva da HwndHost e utilizza INativeHandleContract. Un'istanza di questa classe viene restituita da ContractToViewAdapter all'applicazione host.
HwndHost è disponibile per visualizzare UIs, identificate da handle della finestra, da UIs WPF. Per ulteriori informazioni, vedere Interoperatività di WPF e Win32.
In sintesi, INativeHandleContract, ViewToContractAdapter e ContractToViewAdapter consentono di passare l'handle della finestra di un'UI WPF da un componente aggiuntivo a un'applicazione host, dove viene incapsulato da HwndHost e visualizzato nell'UI dell'applicazione.
| Nota |
|---|
Dal momento che ottiene HwndHost, l'applicazione host non può convertire l'oggetto restituito da ContractToViewAdapter nel tipo in cui viene implementato dal componente aggiuntivo, ad esempio UserControl. |
Per sua natura, HwndHost possiede alcune limitazioni che influiscono sul relativo utilizzo da parte delle applicazioni host. Tuttavia, WPF estende HwndHost con diverse funzionalità per gli scenari del componente aggiuntivo. Di seguito vengono riportati i vantaggi e le limitazioni.
Vantaggi dei componenti aggiuntivi WPF
Poiché le UIs dei componenti aggiuntivi WPF vengono visualizzate dalle applicazioni host tramite una classe interna derivante da HwndHost, tali UIs sono vincolate dalle funzionalità di HwndHost relative ai servizi dell'UI WPF quali layout, rendering, associazione dati, stili, modelli e risorse. Tuttavia, WPF integra la sottoclasse HwndHost interna con funzionalità aggiuntive che includono quanto segue:
Passaggio dall'UI di un'applicazione host all'UI di un componente aggiuntivo e viceversa. Il modello di programmazione "componente aggiuntivo che rappresenta un'UI" richiede che l'adattatore sul lato componente aggiuntivo esegua l'override di QueryContract per consentire tale passaggio, indipendentemente dal fatto che il componente sia completamente attendibile o parzialmente attendibile.
Rispetto dei requisiti di accessibilità per le UIs dei componenti aggiuntivi visualizzate dalle UIs delle applicazioni host.
Esecuzione sicura delle applicazioni WPF in diversi scenari del dominio dell'applicazione.
Protezione contro l'accesso illegale agli handle della finestra dell'UI del componente aggiuntivo in caso di esecuzione dei componenti aggiuntivi con isolamento di sicurezza, vale a dire una sandbox di sicurezza con attendibilità parziale. La chiamata a ViewToContractAdapter garantisce questa sicurezza:
Nel caso del modello di programmazione "componente aggiuntivo che restituisce un'UI", l'unico modo per passare l'handle della finestra per l'UI di un componente aggiuntivo oltre il limite di isolamento consiste nella chiamata a ViewToContractAdapter.
Nel caso del modello di programmazione "componente aggiuntivo che rappresenta un'UI", si richiede l'override di QueryContract nell'adattatore sul lato componente aggiuntivo e la chiamata a ViewToContractAdapter, come illustrato negli esempi precedenti, nonché la chiamata all'implementazione QueryContract dello stesso adattatore dall'adattatore sul lato host.
Protezione dell'esecuzione per più domini dell'applicazione. A causa delle limitazioni relative ai domini dell'applicazione, le eccezioni non gestite generate nei domini dell'applicazione del componente aggiuntivo provocano un arresto anomalo dell'intera applicazione, nonostante sia presente un limite di isolamento. Tuttavia, WPF e il modello di componente aggiuntivo .NET Framework offrono un modo semplice per ovviare al problema e migliorare la stabilità dell'applicazione. Un componente aggiuntivo WPF che visualizza un'UI crea un oggetto Dispatcher per il thread nel quale viene eseguito il dominio dell'applicazione, nel caso in cui l'applicazione host sia un'applicazione WPF. Per rilevare tutte le eccezioni non gestite che si verificano nel dominio dell'applicazione, è possibile gestire l'evento UnhandledException dell'oggetto Dispatcher del componente aggiuntivo WPF. È possibile ottenere Dispatcher dalla proprietà CurrentDispatcher.
Limitazioni dei componenti aggiuntivi WPF
Oltre ai vantaggi aggiunti da WPF ai comportamenti predefiniti forniti da HwndSource, HwndHost e dagli handle della finestra, esistono anche alcune limitazioni per le UIs dei componenti aggiuntivi visualizzate dalle applicazioni host:
Le UIs del componente aggiuntivo visualizzate da un'applicazione host non rispettano il comportamento dell'area di visualizzazione dell'applicazione stessa.
Il concetto di spazio aereo degli scenari di interoperabilità viene applicato anche ai componenti aggiuntivi; vedere in proposito Cenni preliminari sulle aree di tecnologia.
I servizi dell'UI di un'applicazione host, ad esempio l'ereditarietà delle risorse, l'associazione dati e i comandi non sono automaticamente disponibili per le UIs del componente aggiuntivo. Per fornire questi servizi al componente aggiuntivo è necessario aggiornare la pipeline.
L'UI di un componente aggiuntivo non può essere ruotata, ridimensionata, inclinata né trasformata in altro modo; vedere in proposito Cenni preliminari sulle trasformazioni.
Il contenuto delle UIs del componente aggiuntivo sottoposto a rendering mediante operazioni di disegno dallo spazio dei nomi System.Drawing può includere la fusione alfa. Tuttavia, sia l'UI di un componente aggiuntivo che l'UI dell'applicazione host che lo contiene devono essere opache al 100%; in altre parole, la proprietà Opacity di entrambe deve essere impostata su 1.
Se la proprietà AllowsTransparency di una finestra nell'applicazione host contenente l'UI di un componente aggiuntivo è impostata su true, il componente risulta invisibile. Questo accade anche se l'UI del componente aggiuntivo è opaca al 100%, ovvero se la proprietà Opacity ha un valore pari a 1.
L'UI di un componente aggiuntivo deve essere visualizzata in cima ad altri elementi WPF nella stessa finestra di primo livello.
Nessuna parte dell'UI di un componente aggiuntivo può essere sottoposta a rendering mediante un oggetto VisualBrush. Il componente aggiuntivo può invece eseguire uno snapshot dell'UI generata per creare una bitmap da passare all'applicazione host utilizzando i metodi definiti dal contratto.
I file multimediali non possono essere riprodotti da un oggetto MediaElement nell'UI di un componente aggiuntivo.
Gli eventi del mouse generati per l'UI del componente aggiuntivo non vengono ricevuti né generati dall'applicazione host e la proprietà IsMouseOver dell'UI dell'applicazione è impostata su false.
Quando lo stato attivo passa da un controllo a un altro nell'UI di un componente aggiuntivo, gli eventi GotFocus e LostFocus non vengono ricevuti né generati dall'applicazione host.
La parte di un'applicazione host contenente l'UI di un componente aggiuntivo appare bianca quando viene stampata.
Se l'applicazione host prosegue con l'esecuzione, tutti i dispatcher (vedere Dispatcher) creati dall'UI del componente aggiuntivo devono essere arrestati manualmente prima che il componente aggiuntivo proprietario venga scaricato. Il contratto può implementare metodi che consentono all'applicazione host di segnalare il componente aggiuntivo prima che questo venga scaricato, permettendo così all'UI del componente di arrestare i dispatcher.
Se l'UI di un componente aggiuntivo è un oggetto InkCanvas o contiene un oggetto InkCanvas, non è possibile scaricare tale componente.
Ottimizzazione delle prestazioni
Per impostazione predefinita, quando si utilizzano più domini dell'applicazione, tutti gli assembly .NET Framework richiesti da ogni applicazione vengono caricati nel dominio della stessa. Di conseguenza, il tempo necessario per creare nuovi domini dell'applicazione e avviare le applicazioni al loro interno potrebbe influire sulle prestazioni. .NET Framework fornisce tuttavia un metodo per ridurre i tempi di avvio, indicando alle applicazioni di condividere gli assembly tra i vari domini dell'applicazione, se già caricati. A tal proposito, occorre utilizzare l'attributo LoaderOptimizationAttribute, che deve essere applicato al metodo del punto di ingresso (Main). In questo caso, è necessario utilizzare soltanto il codice per implementare la definizione dell'applicazione; vedere in proposito Cenni preliminari sulla gestione di applicazioni.
Vedere anche
Riferimenti
Concetti
Componenti aggiuntivi ed estensibilità