Freigeben über

Änderungen der Debug-API in .NET Framework 2.0

  • Artikel

In diesem Thema werden Änderungen in .NET Framework, Version 2.0, erläutert, die Sie bei Verwendung der Debug-API der Common Language Runtime (CLR) beachten sollten.

API-Änderungen

  • CorDebug ist keine Co-Klasse mehr. Verwenden Sie anstelle von CoCreate die globale statische CreateDebuggingInterfaceFromVersion-Funktion in der Hosting-API. Die Debuggerversion sollte einer der Konstanten aus der CorDebugInterfaceVersion-Enumeration in CorDebug.idl entsprechen. (Verwenden Sie die CorDebugVersion_2_0-Konstante, wenn der Debugger .NET Framework 2.0 unterstützt.) Verwenden Sie die globale statische GetVersionFromProcess-Funktion in der Hosting-API, um die zu debuggende Version für einen laufenden Prozess abzurufen. Alternativ können Sie die globale statische GetRequestedRuntimeVersion-Funktion in der Hosting-API verwenden, um eine Schätzung der Version zu erhalten, die für eine bestimmte EXE-Datei auf der Festplatte geladen wird, oder den Benutzer bitten, eine Version der Laufzeit auszuwählen. (Mit der globalen statischen GetRequestedRuntimeInfo-Funktion in der Hosting-API können Sie bestimmen, ob die vom Benutzer bereitgestellte Zeichenfolge einer gültigen Version entspricht.) All diese Funktionen sind in MSCorEE.idl definiert.

  • Ein Debugger muss die ICorDebugManagedCallback2-Schnittstelle implementieren, um als .NET Framework 2.0-fähiger Debugger erkannt zu werden.

  • ICorDebugEnum-Rückgabewerte sind in .NET Framework 2.0 COM-kompatibel.

  • Neue ICorDebugInternalFrame-Objekte können in Stapelüberwachungen auftreten, denen von der Laufzeit ein spezieller Frame zur Durchführung einer Aufgabe hinzugefügt wurde. Diese Frames reagieren nicht auf eine QueryInterface-Abfrage der ICorDebugNativeFrame-Schnittstelle oder der ICorDebugILFrame-Schnittstelle.

  • Das Timeout für die ICorDebugController::Stop-Methode wird ignoriert.

  • Möglicherweise verwenden Sie die ICorDebugModule::EnableJITDebugging-Methode nur, wenn das Modul zuerst geladen wird. Wenn diese Methode in einem ModuleLoad-Rückruf verwendet wird, der als Teil eines attach-Vorgangs ausgegeben wird, tritt ein Fehler auf. (Durch diese Beschränkung wird sichergestellt, dass das Modul für all seine Funktionen über konsistenten Code verfügt.)

  • Der systemeigene Code für eine bestimmte Funktion in .NET Framework befindet sich möglicherweise nicht in einem zusammenhängenden Speicherblock. Daher sollten Debugger die GetAddress, GetSize-Methode und die GetCode-Methode der ICorDebugCode-Schnittstelle nicht mehr verwenden. Stattdessen sollten sie ICorDebugCode2::GetCodeChunks und ICorDebugProcess::ReadMemory verwenden.

  • Debugger im gemischten Modus müssen nicht verwaltete Haltepunkte festlegen, indem sie die neue ICorDebugProcess2::SetUnmanagedBreakpoint-Methode verwenden.

  • Das systemeigene Debugereignis zur Threadbeendigung erfolgt in .NET Framework 2.0 out-of-band.

  • Objekte in der Debug-API werden aggressiver ungültig gemacht. Wenn ein Vorgang, der in .NET Framework 1.0 oder 1.1 erfolgreich war, in .NET Framework 2.0 CORDBG_E_OBJECT_NEUTERED zurückgibt, hat die Schnittstelle, die für den Vorgang verwendet wurde, ihre Gültigkeit verloren und sollte neu abgerufen werden. Möglicherweise waren die Werte, die aus den Vorgängen in .NET Framework 1.0 und 1.1 abgerufen wurden, falsch.

Generika

Mit der Einführung von Generika in .NET Framework 2.0 werden zahlreiche Annahmen, von denen ein Debugger in früheren Versionen möglicherweise ausging, außer Kraft gesetzt. Debugger sollten die folgenden generikafähigen ICorDebug-Funktionen verwenden:

Siehe auch

Konzepte

Übersicht über das Debugging in der CLR

Weitere Ressourcen

Debuggen (Referenz zur nicht verwalteten API)