Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Aggiornamento: novembre 2007
In questo argomento viene descritto il modo in cui l'API di debug di Common Language Runtime gestisce gli scenari di debug tipici. Notare che CLR supporta alcuni scenari direttamente e interagisce con i metodi correnti per supportarne altri.
Debug out-of-process
Nel debug out-of-process, il debugger si trova in un processo diverso da quello sottoposto a debug, ossia è esterno all'oggetto del debug. Questo scenario riduce le interazioni tra il debugger e l'oggetto del debug. Fornisce pertanto un quadro più preciso del processo.
L'API di debug di CLR supporta direttamente il debug out-of-process. L'API gestisce tutte le comunicazioni tra il debugger e le parti gestite dell'oggetto del debug per supportare il debug del codice gestito.
Sebbene l'API di debug di CLR venga utilizzata in modalità out-of-process, una parte della logica di debug (ad esempio la sincronizzazione dei thread) avrà luogo in-process con l'oggetto del debug. Nella maggior parte dei casi, si tratta di un dettaglio di implementazione che deve essere trasparente per il debugger. Per ulteriori informazioni sulla sincronizzazione dei thread, vedere Architettura di debug CLR. L'utilizzo out-of-process dell'API di debug comporta lo svantaggio dell'impossibilità di utilizzare l'API per controllare i dettagli arresto anomalo del sistema.
Debug in-process
In .NET Framework versioni 1.0 e 1.1, l'API di debug di CLR supportava un debug in-process limitato, in cui un profiler poteva utilizzare le funzionalità di verifica dell'API di debug. In .NET Framework 2.0, il debug in-process è stato sostituito con un insieme di funzionalità più coerente con l'API di analisi. Per ulteriori informazioni su queste modifiche, fare riferimento alle funzionalità snapshot dello stack e verifica degli oggetti in Cenni preliminari sull'analisi.
Debug di un processo remoto
Nel debug di un processo remoto, l'interfaccia utente del debugger si trova su un computer diverso da quello del processo sottoposto a debug. Questo scenario può essere utile in caso di interferenze da parte del debugger con l'oggetto del debug quando entrambi sono in esecuzione sullo stesso computer, a causa di risorse limitate, dipendenze di posizione o bug che interferiscono con il sistema operativo.
L'API di debug di CLR non supporta il debug diretto di un processo remoto. Un debugger basato sull'API di debug di CLR deve comunque essere di tipo out-of-process rispetto all'oggetto del debug. Pertanto, questa soluzione richiederà un processo proxy sullo stesso computer dell'oggetto del debug.
Debug di codice non gestito
Poiché il codice gestito può coesistere nello stesso processo insieme al codice non gestito, è probabile che l'utente desideri eseguire il debug di entrambi i tipi di codice contemporaneamente.
L'API di debug di CLR non supporta il debug diretto di codice non gestito. Tuttavia, la coesistenza con un debugger di codice non gestito è possibile mediante la condivisione delle funzionalità di debug di Win32. Sono disponibili inoltre funzionalità per supportare il debug passo a passo nei limiti fra codice gestito e codice non gestito.
L'API di debug di CLR fornisce due opzioni per il debug di un processo:
Un'opzione soft-attach in cui vengono sottoposte al debug solo le parti gestite del processo. Tale opzione consente a un debugger di disconnettersi dal processo in cui è in corso il debug al termine dell'operazione.
Un'opzione hard-attach, in cui sia le parti gestite, sia quelle non gestite di un processo sono sottoposte al debug e tutti gli eventi di debug di Win32 vengono esposti tramite l'API di debug.
Ambienti con linguaggi misti
Nel software dei componenti, componenti diversi possono essere stati generati con linguaggi differenti. Un debugger deve riconoscere se il codice è originato in un linguaggio diverso, in modo da poter visualizzare i dati nel formato corretto, valutare le espressioni con la sintassi appropriata e così via.
L'API di debug di CLR non fornisce supporto diretto per gli ambienti con linguaggi misti, in quanto CLR non riconosce il linguaggio di origine. Le funzionalità di mapping dell'origine disponibili in un debugger devono consentire l'esecuzione del mapping di una determinata funzione al linguaggio in cui la funzione è stata implementata.
Processi multipli e programmi distribuiti
Il programma di un componente può includere l'interazione tra componenti in esecuzione in processi diversi o anche su computer diversi di una rete. Un debugger deve essere in grado di analizzare la logica di esecuzione tra processi e computer per fornire una vista logica delle operazioni in corso.
L'API di debug di CLR non fornisce supporto diretto per il debug di più processi. Anche in questo caso, un debugger che sta utilizzando l'API deve fornire direttamente tale supporto e garantire il funzionamento dei metodi disponibili a tal fine.