Debug di MEF
I problemi di debug in MEF (Managed Extensibility Framework) possono essere difficili, poiché i problemi potenziali sono diversi da quelli presenti in un'applicazione comune. In questo argomento vengono descritti i suggerimenti per la diagnostica di problemi specifici di MEF e vengono suggerite alcune possibili cause di tali problemi.
Individuazione di un problema di MEF
Il primo passaggio nella soluzione di un problema di MEF consiste nell'individuare il problema nella parte MEF dell'applicazione. Nella tabella seguente sono elencati i problemi specifici di MEF.
Problema |
Possibili cause |
|---|---|
Eccezione ImportCardinalityMismatchException generata durante la composizione. |
Impossibile soddisfare un'importazione con un'esportazione della corrispondenza a causa di una parte mancante o rifiutata. - oppure - In un'importazione in cui era prevista una singola esportazione sono state rilevate più corrispondenze. |
Contenuto previsto mancate in una raccolta con l'attributo ImportManyAttribute. |
Le parti previste sono mancanti o sono state rifiutate. |
Un'importazione con l'attributo DefaultValueAttribute impostato su true non è stata soddisfatta in modo imprevisto. |
Una corrispondenza prevista è mancante o è stata rifiutata. |
Gestione delle eccezioni e DisableSilentRejection
MEF è progettato per adattarsi in modo affidabile alle diverse configurazioni. Per impostazione predefinita, ignora le parti in cui mancano dipendenze necessarie. Tuttavia, quando si esegue il debug dell'applicazione, questa affidabilità può rendere più difficile individuare la causa esatta di un problema. È possibile eseguire questi passaggi per tenere traccia dei problemi più facilmente:
Configurare il debugger di Visual Studio in modo che venga interrotto quando vengono generate eccezioni.
Configurare l'oggetto CompositionContainer per disabilitare il rifiuto.
Generalmente se un'app genera un'eccezione, il debugger di Visual Studio interromperà l'esecuzione solo se tale eccezione non viene successivamente gestita. Tuttavia, potrebbe essere utile arrestare ed eseguire il debug di un'applicazione MEF immediatamente quando viene generata un'eccezione, perché l'applicazione potrebbe gestirla in modo che non si presenti al debugger. Per configurare il debugger di Visual Studio in modo che si interrompa in presenza di eccezioni, nella barra dei menu scegliere Debug, Eccezioni. Assicurarsi che la casella Generata sia selezionata per tutte le eccezioni in corrispondenza delle quali si desidera che il debugger interrompa l'esecuzione. (Per MEF, queste sono le eccezioni in System.ComponentModel.Composition. Per ulteriori informazioni, vedere Procedura: interrompere l'esecuzione in caso di eccezione). Queste eccezioni verranno visualizzate nel debugger, anche se sono gestite dall'app.
Per impostazione predefinita, il FRAMEWORK utilizza un processo chiamato rifiuto per determinare quali parti dispongono di tutte le dipendenze necessarie per la creazione di istanze. Il motore di composizione controlla se l'aggiunta di nuove parti ha generato il fallimento della composizione. Se possono causare l'errore, tali parti vengono nascoste al contenitore, ma non verrà generata alcuna eccezione. Questo comportamento dà come risultato un'applicazione che è più stabile di fronte a varie configurazioni di distribuzione ma che rende più difficile il debug. Per disattivare il rifiuto e accertarsi che tramite MEF sia generata un'eccezione ogni volta che una parte viene rifiutata, passare il valore DisableSilentRejection all'oggetto ExportProvider o CompositionContainer. Il metodo è illustrato nel codice seguente:
var catalog = new DirectoryCatalog("Extensions");
var container = new CompositionContainer(catalog, CompositionOptions.DisableSilentRejection);
Determinazione delle cause radice
Gli errori MEF sono spesso sovrapposti, ovvero un errore per comporre una parte comporta l'impossibilità di creare una seconda parte e così via, fino a che il punto di errore osservato si perde in un lungo elenco di eccezioni. Per semplificare la diagnosi dei problemi di questa natura, l'eccezione CompositionException fornisce la proprietà RootCauses. È possibile esaminare la proprietà nel debugger per individuare l'eccezione che è la causa radice di ogni errore di composizione.
Tracciatura
A partire da .NET Framework 4,5, il framework MEF supporta l'analisi. Gli errori e le eccezioni di composizione sono scritti nella finestra IntelliTrace durante l'esecuzione in modalità debug in Visual Studio. L'esame dei risultati può contribuire a diagnosticare gli errori di composizione. Per ulteriori informazioni su IntelliTrace vedere Eseguire il debug dell'app registrando l'esecuzione del codice con IntelliTrace.
Esame delle parti disponibili
Per determinare le parti disponibili per il catalogo, è possibile esaminare la proprietà Parts del catalogo nel debugger, o scorrere tale proprietà nel codice.
Se le parti previste non sono presenti, significa che non sono state individuate o che sono state rifiutate.
Se è possibile visualizzare una parte, ma non è corrispondente all'importazione prevista, si è verificato un tipo di mancata corrispondenza. Per ulteriori informazioni, vedere la sezione successiva.
Mancate corrispondenze di esportazione/importazione
Per ottenere una corrispondenza tra un'importazione e un'esportazione, è necessario che vengano soddisfatte tutte le condizioni seguenti. Se non si verifica una corrispondenza prevista ma è stato confermato che l'esportazione è presente nel catalogo, controllare attentamente queste condizioni. Le condizioni si applicano anche quando si costruisce manualmente un contratto affinché corrisponda a una specifica esportazione. Per ulteriori informazioni, vedere il metodo ExportProvider.GetExports.
Proprietà |
Condizioni per la corrispondenza |
|---|---|
Nome contratto |
Deve corrispondere esattamente e viene fatta distinzione tra maiuscole e minuscole. Nel caso dei nomi di contratto dedotti dai tipi, ad esempio quando l'attributo ExportAttribute viene applicato senza parametri, l'unica corrispondenza possibile è un altro nome dedotto dallo stesso tipo. |
Tipo di contratto |
Deve corrispondere esattamente. La corrispondenza polimorfica non è supportata. I tipi di contratto devono corrispondere anche se vengono forniti i nomi di contratto corrispondenti. |
Metadati richiesti |
Tutti i metadati richiesti dall'importazione tramite le proprietà della relativa visualizzazione dei metadati devono essere forniti dall'esportazione tramite l'attributo ExportMetadataAttribute o un attributo dei metadati personalizzato. Sia le chiavi dei metadati, ovvero i nomi delle proprietà nella visualizzazione dei metadati, che i tipi dei valori dei metadati devono corrispondere. |
Creazione dei criteri |
L'esportazione e l'importazione non devono specificare criteri di creazione diversi. Per ulteriori informazioni, vedere l'enumerazione CreationPolicy. |
Problemi di individuazione
Se una parte non viene visualizzata nel catalogo o viene visualizzata quando si utilizza lo strumento di analisi composizione Mefx, tale parte non viene individuata dal catalogo. Questo errore può essere determinato da alcune cause:
La parte è un tipo astratto. I tipi astratti non possono essere utilizzati come parti. Rendere il tipo non astratto o creare un sottotipo non astratto.
L'attributo ImportingConstructorAttribute risulta mancante. Una parte con più costruttori, o con solo costruttori che accettano parametri, deve specificare un costruttore per MEF da utilizzare con l'attributo ImportingConstructorAttribute.
La parte contiene l'attributo PartNotDiscoverableAttribute. Questo attributo impedisce l'individuazione di una parte.
La parte è un tipo generico aperto. MEF non supporta i tipi generici aperti. Utilizzare una sottoclasse del tipo chiusa o esportare le singole proprietà.
Ulteriori errori possono verificarsi quando si utilizza un oggetto DirectoryCatalog:
La parte si trova in un file EXE. L'oggetto DirectoryCatalog predefinito legge solo dai file DLL. È possibile utilizzare un oggetto DirectoryCatalog per leggere da altri file creandolo con il modello di ricerca appropriato.
L'assembly della parte ha un riferimento mancante. Gli assembly utilizzati devono essere in grado di caricare i relativi riferimenti dal percorso di ricerca, in genere dalla propria directory o dalla Global Assembly Cache.
L'assembly della parte fa riferimento a un tipo di CPU diverso. MEF non carica gli assembly che fanno riferimento al tipo di CPU non corretto.