Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este tópico explica as alterações no .NET estrutura versão 2.0 que você deve considerar ao usar o common linguagem tempo de execução (CLR) API de depuração.
Alterações de API
CorDebug não é mais uma coclass. Em vez de co-creating-lo, use o CreateDebuggingInterfaceFromVersion função estática global na API de hospedagem. A versão de depurador deve ser uma das constantes do CorDebugInterfaceVersion enumeração no CorDebug.idl. (Use o CorDebugVersion_2_0 constante se o depurador oferecer suporte a .NET estrutura 2.0.) Use o GetVersionFromProcess global estático função na API de hospedagem para obter a versão de depuração de um processo em execução. Ou você pode usar o GetRequestedRuntimeVersion função estática global na API de hospedagem obter uma melhor estimativa para a versão que será carregada para um arquivo .exe determinado em disco ou peça ao usuário selecionar uma versão do tempo de execução. (Você pode usar o GetRequestedRuntimeInfo estático função 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 o ICorDebugManagedCallback2 interface para que seja reconhecido sistema autônomo um depurador 2.0 compatível com .NET estrutura.
ICorDebugEnum valores de retorno são compatíveis com o .NET estrutura 2.0.
New ICorDebugInternalFrame objetos podem aparecer nos rastreamentos de pilha onde o tempo de execução foi inserido um quadro especial para realizar algumas tarefas. Esses quadros não responderá a um QueryInterface consulta de um a ICorDebugNativeFrame or ICorDebugILFrame interface.
O time limite para o ICorDebugController::Stop método será ignorado.
Você pode usar o ICorDebugModule::EnableJITDebugging método somente quando o módulo é primeiro carregado. Se esse método é usado em um ModuleLoad retorno de chamada que é emitido sistema autônomo parte de um attach operação, ele falhará. (Essa restrição garante que o módulo tenha código consistente para todas as suas funções.)
O código nativo para uma determinada função no .NET estrutura não pode estar em um único bloco contíguo de memória. sistema autônomo resultado, depuradores não devem usar o GetAddress, GetSize, e GetCode métodos para o ICorDebugCode interface. Em vez disso, eles devem usar ICorDebugCode2::GetCodeChunks and ICorDebugProcess::ReadMemory.
Depuradores de modo misto devem conjunto pontos de interrupção não gerenciados usando o novo ICorDebugProcess2::SetUnmanagedBreakpoint método.
O evento de depurar de sair de thread nativo é fora de banda no .NET estrutura 2.0.
Objetos na API de depuração são invalidados forma mais agressiva. Se uma operação bem-sucedida no .NET estrutura 1.0 ou 1.1 retorna CORDBG_E_OBJECT_NEUTERED no .NET estrutura 2.0, a interface na qual a operação foi executada excedeu sua tempo de vida e deve ser re-obtained. Os valores que foram obtidos a partir as operações no .NET estrutura 1.0 e 1.1 não podem ter sido corretos.
Genéricos
A introdução de genéricos no .NET estrutura 2.0 quebras muitas suposições que um depurador pode ter feito em versões anteriores. Depuradores devem mover a usar 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, and ICorDebugEval2::CreateValueForType em vez de suas contrapartes no ICorDebugEval interface.
Use ICorDebugFunction2::EnumerateNativeCode em vez de ICorDebugFunction::GetNativeCode.