Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Actualización: noviembre 2007
En este tema se describe cómo administra la API de depuración de Common Language Runtime (CLR) los escenarios de depuración típicos. Observe que CLR admite directamente algunos escenarios e interopera con métodos actuales para admitir otros.
Depuración fuera de proceso
En la depuración fuera de proceso, el depurador está en un proceso independiente del proceso que se depura (es decir, está fuera del código que está siendo depurado). Este escenario reduce las interacciones entre el depurador y el código que está siendo depurado. Por consiguiente, habilita una imagen más precisa del proceso.
La API de depuración de CLR admite directamente la depuración fuera de proceso. La API administra toda la comunicación entre el depurador y las partes administradas del código que está siendo depurado para admitir la depuración de código administrado.
Aunque la API de depuración de CLR se utiliza fuera de proceso, parte de la lógica de depuración (por ejemplo, la sincronización de subprocesos) se produce fuera de proceso con el código que está siendo depurado. En la mayoría de los casos, éste es un detalle de implementación que debe ser transparente para el depurador. Para obtener más información sobre la sincronización de subprocesos, vea Arquitectura de depuración de CLR. Una desventaja es que la API de depuración no se puede utilizar para inspeccionar volcados de sucesos cuando se utiliza fuera de proceso.
Depuración en proceso
En las versiones 1.0 y 1.1 de .NET Framework, la API de depuración de CLR admitía una depuración en proceso limitada, en la que un generador de perfiles podía utilizar las características de inspección de la API de depuración. En .NET Framework 2.0, la depuración en proceso se ha reemplazado por un conjunto de funciones más coherente con la API de generación de perfiles. Para obtener más información sobre estos cambios, vea las características de captura de la pila e inspección de objetos en Información general sobre la generación de perfiles.
Depuración de procesos remotos
En la depuración de procesos remotos, la interfaz de usuario del depurador está en un equipo independiente del proceso que se depura. Este escenario puede ser útil si el depurador interfiere con el código que está siendo depurado cuando se están ejecutando en el mismo equipo, debido a recursos limitados, dependencias de la ubicación o errores de programación que interfieren con el sistema operativo.
La API de depuración de CLR no admite directamente la depuración de procesos remotos. Aún debe existir un depurador basado en la API de depuración de CLR fuera de proceso del código que está siendo depurado. Por consiguiente, esta solución requiere un proceso proxy en el mismo equipo que el código que está siendo depurado.
Depuración de código no administrado
Dado que el código administrado puede coexistir en el mismo proceso que código no administrado, con frecuencia el usuario deseará depurar al mismo tiempo ambos tipos de código.
La API de depuración de CLR no admite directamente la depuración de código no administrado. Sin embargo, pueden coexistir con un depurador de código no administrado compartiendo los medios de depuración de Win32. Además, se proporcionan medios para permitir el recorrido paso a paso a través de los límites entre código administrado y código no administrado.
Además, la API de depuración de CLR proporciona dos opciones para depurar un proceso:
Una opción de asociación flexible en la que se depura solamente las partes administradas del proceso. Un depurador con asociación flexible a un proceso puede desasociarse después del proceso.
Una opción de asociación rígida en la que se depura tanto las partes administradas de un proceso como las no administradas y todos los eventos de depuración de Win32 se exponen a través de la API de depuración.
Entornos de lenguaje mixto
En software de componentes, diferentes componentes pueden generarse con lenguajes diferentes. Un depurador debe entender cuándo está el código en un lenguaje diferente, para poder mostrar los datos en el formato correcto, evaluar las expresiones con la sintaxis correcta, etc..
La API de depuración de CLR no proporciona ninguna compatibilidad directa para los entornos de lenguaje mixto, porque CLR no tiene el concepto de lenguaje de origen. Los medios de asignación de origen existente de un depurador deben permitirle asignar una función determinada al lenguaje en el que se implementó la función.
Procesos múltiples y programas distribuidos
Un programa componente puede incluir componentes cooperativos que se están ejecutando en procesos diferentes o incluso en equipos diferentes de una red. Un depurador debería poder seguir paso a paso la lógica de ejecución entre procesos y equipos para proporcionar una vista lógica de lo que está pasando.
La API de depuración de CLR no proporciona compatibilidad directa para la depuración de procesos múltiples. De nuevo, un depurador que está utilizando la API debe proporcionar directamente tal compatibilidad y métodos existentes para hacer que continúe funcionando.