Scegliere una strategia di implementazione del motore di debug
Usare l'architettura di runtime per determinare la strategia di implementazione del motore di debug (DE). È possibile creare il motore di debug in-process per il programma di cui si sta eseguendo il debug. Creare il motore di debug in-process per lo strumento di gestione del debug delle sessioni di Visual Studio. In alternativa, creare il motore di debug out-of-process per entrambi. Le linee guida seguenti consentono di scegliere tra queste tre strategie.
Linee guida
Anche se è possibile che il DE sia out-of-process sia per SDM che per il programma di cui si esegue il debug, in genere non c'è motivo di farlo. Le chiamate attraverso i limiti del processo sono relativamente lente.
I motori di debug sono già disponibili per l'ambiente di runtime nativo Win32 e per l'ambiente di runtime del linguaggio comune. Se è necessario sostituire de de per uno degli ambienti, è necessario creare il de in-process con SDM.
In caso contrario, si crea la de in-process per SDM o in-process al programma di cui si sta eseguendo il debug. È necessario considerare se l'analizzatore di espressioni di DE richiede l'accesso frequente all'archivio dei simboli del programma. In alternativa, se l'archivio simboli può essere caricato in memoria per l'accesso rapido. Considerare anche gli approcci seguenti:
Se non sono presenti molte chiamate tra l'analizzatore di espressioni e l'archivio simboli o se l'archivio simboli può essere letto nello spazio di memoria SDM, creare il de in-process per SDM. È necessario restituire il CLSID del motore di debug a SDM quando si connette al programma. Il SDM usa questo CLSID per creare un'istanza in-process della de.
Se il de deve chiamare il programma per accedere all'archivio simboli, creare il de in-process con il programma. In questo caso, il programma crea l'istanza di DE.