Depurar los cambios de la API en .NET Framework 2.0
En este tema se explican los cambios en la versión 2.0 de .NET Framework que debe tener en cuenta al utilizar la API de depuración de Common Language Runtime (CLR).
Cambios de la API
CorDebug ya no es una co-clase. En lugar de co-crearla, utilice la función estática global CreateDebuggingInterfaceFromVersion en la API host. La versión del depurador debe ser una de las constantes de la enumeración CorDebugInterfaceVersion de CorDebug.idl. (Use la constante CorDebugVersion_2_0 si su depurador admite .NET Framework 2.0.) Emplee la función estática global GetVersionFromProcess en la API de hospedaje para obtener la versión del código que se está depurando para un proceso en ejecución. También puede utilizar la función estática global GetRequestedRuntimeVersion de la API host para obtener una aproximación mejor para la versión que se cargará para un archivo .exe determinado del disco o pide al usuario que elija una versión del motor en tiempo de ejecución. (Puede utilizar la función estática global GetRequestedRuntimeInfo de la API host para determinar si la versión de la cadena proporcionada por el usuario es válida.) Todas estas funciones se definen en MSCorEE.idl.
Un depurador debe implementar la interfaz ICorDebugManagedCallback2 para ser reconocido como un depurador compatible con .NET Framework 2.0.
Los valores devueltos por ICorDebugEnum son conformes con COM en .NET Framework 2.0.
Los objetos ICorDebugInternalFrame nuevos pueden aparecer en seguimientos de la pila donde el motor en tiempo de ejecución ha insertado un marco especial para lograr alguna tarea. Estos marcos no responderán a una consulta QueryInterface para la interfaz ICorDebugNativeFrame o ICorDebugILFrame.
El tiempo de espera al método ICorDebugController::Stop se omite.
Sólo puede utilizar el método ICorDebugModule::EnableJITDebugging cuando se carga el módulo por primera vez. Si este método se utiliza en una devolución de llamada ModuleLoad que se emite como parte de una operación attach, producirá un error. (Esta restricción garantiza que el módulo tiene código coherente para todas sus funciones.)
El código nativo para una función determinada de .NET Framework puede no estar en un bloque de memoria contiguo único. Como resultado, los depuradores ya no deben utilizar los métodos GetAddress, GetSizey GetCode de la interfaz ICorDebugCode. En su lugar, deben utilizar ICorDebugCode2::GetCodeChunks e ICorDebugProcess::ReadMemory.
Los depuradores de modo mixto deben establecer puntos de interrupción no administrados utilizando el nuevo método ICorDebugProcess2::SetUnmanagedBreakpoint.
El evento de depuración de salida de subproceso nativo está fuera de banda en .NET Framework 2.0.
Los objetos de la API de depuración se invalidan más agresivamente. Si una operación que tenía éxito en .NET Framework 1.0 o 1.1 devuelve CORDBG_E_OBJECT_NEUTERED en .NET Framework 2.0, la interfaz en la que se realizó la operación ha superado su duración y debe obtenerse de nuevo. Los valores que se obtuvieron de las operaciones en .NET Framework 1.0 y 1.1 pueden no haber sido correctos.
Genéricos
La introducción de genéricos en .NET Framework 2.0 rompe muchas suposiciones que un depurador podría haber realizado en versiones anteriores. Los depuradores deben pasar a utilizar las siguientes formas compatibles con genéricos de las funciones ICorDebug:
Utilice ICorDebugType::GetStaticFieldValue en lugar de su homólogo en la interfaz ICorDebugClass.
Utilice ICorDebugEval2::CallParameterizedFunction, ICorDebugEval2::NewParameterizedObject, ICorDebugEval2::NewParameterizedObjectNoConstructor, ICorDebugEval2::NewParameterizedArraye ICorDebugEval2::CreateValueForType en lugar de sus homólogos en la interfaz ICorDebugEval.
Utilice ICorDebugFunction2::EnumerateNativeCode en lugar de ICorDebugFunction::GetNativeCode.
Vea también
Conceptos
Información general sobre la depuración en CLR