Een implementatiestrategie voor de foutopsporingsengine kiezen

Gebruik de runtimearchitectuur om de implementatiestrategie voor de foutopsporingsengine (DE) te bepalen. U kunt de foutopsporingsengine binnen hetzelfde proces maken van het programma dat u aan het debuggen bent. Maak de debug-machine in-process voor de Visual Studio Session Debug Manager (SDM). Of maak de foutopsporingsengine buiten het proces voor beiden. Aan de hand van de volgende richtlijnen kunt u kiezen uit deze drie strategieën.

Guidelines

Hoewel het mogelijk is dat de DE buiten het proces om is ten opzichte van zowel de SDM als het programma dat u aan het debuggen bent, is er meestal geen reden om dat te doen. Aanroepen tussen procesgrenzen zijn relatief traag.

Foutopsporingsengines zijn al beschikbaar voor de systeemeigen Win32-runtimeomgeving en voor de algemene runtime-omgeving van de taal. Als u de DE voor een van de omgevingen moet vervangen, moet u de DE in het proces met de SDM creëren.

Anders maakt u de DE binnen het proces naar de SDM of binnen het proces naar het programma dat u aan het debuggen bent. U moet overwegen of de expressie-evaluator van de DE regelmatig toegang tot het programmasymboolarchief vereist. Of als het symboolarchief kan worden geladen in het geheugen voor snelle toegang. Houd ook rekening met de volgende benaderingen:

• Als er niet veel aanroepen zijn tussen de expressie-evaluator en het symboolarchief, of als het symboolarchief kan worden gelezen in de SDM-geheugenruimte, installeert u de DE als een in-procescomponent in de SDM. U moet de CLSID van de foutopsporingsengine retourneren aan de SDM wanneer deze wordt gekoppeld aan uw programma. De SDM gebruikt deze CLSID om een in-process exemplaar van de DE te maken.

• Als de DE het programma moet aanroepen om toegang te krijgen tot het symboolarchief, maakt u de DE in-proces met het programma. In dit geval maakt het programma het exemplaar van de DE.

Verwante inhoud

• Uitbreidbaarheid van Visual Studio-foutopsporingsprogramma