.NET Framework 2.0 中的偵錯 API 變更
本主題將說明在使用 Common Language Runtime (CLR) 偵錯 API 時，.NET Framework 2.0 版中您應該考慮的變更。
API 變更
CorDebug 不再為 coclass。 請使用裝載 API 中的 CreateDebuggingInterfaceFromVersion 全域靜態函式，而不要共同建立。 偵錯工具版本應該是 CorDebug.idl 內 CorDebugInterfaceVersion 列舉型別的其中一個常數 (如果偵錯工具支援 .NET Framework 2.0，請使用 CorDebugVersion_2_0 常數)。請使用裝載 API 中的 GetVersionFromProcess 全域靜態函式，取得執行中處理序的偵錯項目版本。 或者，也可以使用裝載 API 內的 GetRequestedRuntimeVersion 全域靜態函式，以取得版本的最佳猜測 (將對磁碟中指定的 .exe 檔案載入該版本)，或要求使用者選取執行階段的版本 (您可以使用裝載 API 內的 GetRequestedRuntimeInfo 全域靜態函式，判斷使用者提供的字串是否為有效的版本)。所有這些函式都會在 MSCorEE.idl 中加以定義。
偵錯工具必須實作 ICorDebugManagedCallback2 介面，以便識別為具有 .NET Framework 2.0 能力的偵錯工具。
ICorDebugEnum 會傳回 .NET Framework 2.0 中符合 COM 的值。
新的 ICorDebugInternalFrame 物件可能出現在堆疊追蹤中，執行階段會在此追蹤中插入特殊框架，以完成某些工作。 這些框架不會回應 ICorDebugNativeFrame 或 ICorDebugILFrame 介面的 QueryInterface 查詢。
將會忽略 ICorDebugController::Stop 方法的逾時。
您只有在第一次載入模組時，才能使用 ICorDebugModule::EnableJITDebugging 方法。 如果是在 ModuleLoad 回呼中使用這個方法 (會做為 attach 作業的一部分而發出)，則會失敗 (這個限制可確保模組對於所有函式都有一致的程式碼)。
.NET Framework 中指定之函式的機器碼，可能不在記憶體的單一連續區塊中。 因此，偵錯工具應該不再使用 ICorDebugCode 介面的 GetAddress、GetSize 和 GetCode 方法， 而是應該使用 ICorDebugCode2::GetCodeChunks 和 ICorDebugProcess::ReadMemory。
混合模式偵錯工具必須使用新的 ICorDebugProcess2::SetUnmanagedBreakpoint 方法設定 Unmanaged 中斷點。
在 .NET Framework 2.0 中，原生執行緒結束偵錯事件為 Out-of-Band。
偵錯 API 中的物件會更快速地無效化。 如果 .NET Framework 1.0 或 1.1 中成功的作業在 .NET Framework 2.0 中傳回 CORDBG_E_OBJECT_NEUTERED，根據介面所執行的作業會超出其存留期 (Lifetime)，而且必須重新取得。 從 .NET Framework 1.0 和 1.1 中的作業所取得的值可能不正確。
泛型
.NET Framework 2.0 中的泛型簡介會打破偵錯工具在舊版中可能立下的許多假設。 偵錯工具應該改為使用下列 ICorDebug 函式的泛型感知形式：
使用 ICorDebugType::GetStaticFieldValue，而不是它在 ICorDebugClass 介面中的對應項目。
使用 ICorDebugEval2::CallParameterizedFunction、ICorDebugEval2::NewParameterizedObject、ICorDebugEval2::NewParameterizedObjectNoConstructor、ICorDebugEval2::NewParameterizedArray 和 ICorDebugEval2::CreateValueForType，而不是它們在 ICorDebugEval 介面中的對應項目。
使用 ICorDebugFunction2::EnumerateNativeCode，而不使用 ICorDebugFunction::GetNativeCode。