API de alterações na depuração do.NET Framework 2.0
Este tópico explica as alterações na.NET Framework versão 2.0, você deve considerar ao usar o common language runtime (CLR) API de depuração.
Alterações na API
CorDebugnão é mais um coclass. Em vez de co-creating-lo, use o CreateDebuggingInterfaceFromVersion a função estática global na API de hospedagem. A versão de depurador deve ser uma das constantes a partir de CorDebugInterfaceVersion enumeração de CorDebug.idl. (Use o CorDebugVersion_2_0 constante se o depurador oferece suporte a.NET Framework 2.0.) Use o GetVersionFromProcess a função estática global na API de hospedagem para obter a versão de depuração para um processo em execução. Ou você pode usar o GetRequestedRuntimeVersion a função estática global na API de hospedagem para obter uma melhor estimativa para a versão que será carregada para um arquivo. exe de determinado no disco ou solicitar que o usuário selecione uma versão do runtime. (Você pode usar o GetRequestedRuntimeInfo a função estática global na API de hospedagem para determinar se a seqüência de caracteres fornecido pelo usuário é uma versão válida.) Todas essas funções são definidas em MSCorEE.idl.
Um depurador deve implementar a ICorDebugManagedCallback2 interface para ser reconhecido como um.Depurador do NET Framework 2.0 compatível com.
ICorDebugEnum valores de retorno estão em conformidade COM na.NET Framework 2.0.
Nova ICorDebugInternalFrame objetos podem aparecer nos rastreamentos de pilha onde o runtime tenha inserido um quadro especial para realizar algumas tarefas. Esses quadros não responderá a um QueryInterface a consulta para um de ICorDebugNativeFrame ou ICorDebugILFrame interface.
O tempo limite para o ICorDebugController::Stop método será ignorado.
Você pode usar o ICorDebugModule::EnableJITDebugging método somente quando o módulo é carregado pela primeira vez. Se esse método é usado em um ModuleLoad retorno de chamada que é emitido como parte de um attach operação, ele irá falhar. (Essa restrição garante que o módulo tem código consistente para todas as suas funções).
O código nativo para uma determinada função na.NET Framework pode não estar em um único bloco contíguo de memória. Como resultado, os depuradores não devem mais usar o GetAddress, GetSize, e GetCode métodos para a ICorDebugCode interface. Em vez disso, eles devem usar ICorDebugCode2::GetCodeChunks e ICorDebugProcess::ReadMemory.
Depuradores de modo misto devem definir pontos de interrupção não gerenciados usando o novo ICorDebugProcess2::SetUnmanagedBreakpoint método.
O evento de depuração de saída de thread nativo é out-of-band na.NET Framework 2.0.
Objetos na API de depuração são invalidados de forma mais agressiva. Se uma operação que teve êxito na.NET Framework 1.0 ou 1.1 retorna CORDBG_E_OBJECT_NEUTERED na.NET Framework 2.0, a interface na qual a operação foi executada excedeu a sua vida útil e deve ser re-obtained. Os valores que foram obtidos de operações na.NET Framework 1.0 e 1.1 podem não ter sido corretos.
Genéricos
A introdução de genéricos na.NET Framework 2.0 quebras muitas suposições que um depurador pode ter feito em versões anteriores. Depuradores devem se mover para com os seguintes formulários de reconhecimento de genéricos de ICorDebug funções:
Use ICorDebugType::GetStaticFieldValue em vez de sua contraparte no ICorDebugClass interface.
Use ICorDebugEval2::CallParameterizedFunction, ICorDebugEval2::NewParameterizedObject, ICorDebugEval2::NewParameterizedObjectNoConstructor, ICorDebugEval2::NewParameterizedArray, e ICorDebugEval2::CreateValueForType em vez de suas contrapartes na ICorDebugEval interface.
Use ICorDebugFunction2::EnumerateNativeCode em vez de ICorDebugFunction::GetNativeCode.
Consulte também
Conceitos
Visão geral de depuração do CLR