Native Debuggerobjekte in JavaScript-Erweiterungen – Überlegungen zum Entwerfen und Testen
In diesem Thema werden Entwurfs- und Testüberlegungen für die Verwendung der nativen Debuggerobjekte in JavaScript-Erweiterungen beschrieben.
Native Debuggerobjekte stellen verschiedene Konstrukte und Verhaltensweisen der Debuggerumgebung dar. Die Objekte können an JavaScript-Erweiterungen übergeben (oder in erworben werden), um den Zustand des Debuggers zu ändern.
Informationen zu JavaScript-Erweiterungen des Debuggerobjekts finden Sie unter Native Debugger-Objekte in JavaScript-Erweiterungen.
Allgemeine Informationen zum Arbeiten mit JavaScript finden Sie unter JavaScript-Debuggerskripting.
Überlegungen zum Entwurf des Debuggerdatenmodells
Entwurfsprinzipien
Berücksichtigen Sie die folgenden Prinzipien, damit Ihre Debuggererweiterungen Informationen darstellen, die auffindbar, abfragbar und skriptfähig sind.
- Informationen sind nah an dem Ort, an dem sie benötigt werden. Beispielsweise sollten Informationen zu einem Registrierungsschlüssel als Teil einer lokalen Variablen angezeigt werden, die ein Registrierungsschlüsselhandle enthält.
- Informationen sind strukturiert. Beispielsweise werden Informationen zu einem Registrierungsschlüssel in separaten Feldern wie Schlüsseltyp, Schlüssel-ACL, Schlüsselname und Wert angezeigt. Das bedeutet, dass auf die einzelnen Felder ohne Analysetext zugegriffen werden kann.
- Informationen sind konsistent. Informationen zu Registrierungsschlüsselhandles werden so ähnlich wie möglich dargestellt wie Informationen zu Dateihandles.
Vermeiden Sie diese Ansätze, die diese Prinzipien nicht unterstützen.
- Strukturieren Sie Ihre Artikel nicht in eine einzelne flache "Küchenspüle". Eine organisierte Hierarchie ermöglicht es Benutzern, nach den gesuchten Informationen zu suchen, ohne vorher zu wissen, wonach sie suchen, und unterstützt die Auffindbarkeit.
- Konvertieren Sie eine klassische dbgeng-Erweiterung nicht, indem Sie sie einfach in das Modell verschieben, während Sie weiterhin Bildschirme mit Rohtext ausgeben. Dies kann nicht mit anderen Erweiterungen erstellt werden und kann nicht mit LINQ-Ausdrücken abgefragt werden. Unterteilen Sie die Daten stattdessen in separate, abfragbare Felder.
Richtlinien für die Benennung
- Die Groß-/Kleinschreibung von Feldern sollte PascalCase sein. Eine Ausnahme könnte für Namen in Betracht gezogen werden, die in einer anderen Groß- und Kleinschreibung allgemein bekannt sind, z. B. jQuery.
- Vermeiden Sie die Verwendung von Sonderzeichen, die normalerweise nicht in einem C++-Bezeichner verwendet werden. Vermeiden Sie beispielsweise Die Verwendung von Namen wie "Gesamtlänge" (die ein Leerzeichen enthält) oder "[size]" (die eckige Klammern enthält). Diese Konvention ermöglicht eine einfachere Verwendung von Skriptsprachen, in denen diese Zeichen nicht als Teil von Bezeichnern zulässig sind, und ermöglicht auch eine einfachere Verwendung aus dem Befehlsfenster.
Organisations- und Hierarchierichtlinien
- Erweitern Sie nicht die oberste Ebene des Debuggernamespaces. Stattdessen sollten Sie einen vorhandenen Knoten im Debugger erweitern, sodass die Informationen dort angezeigt werden, wo sie am relevantesten sind.
- Duplizieren Sie keine Konzepte. Wenn Sie eine Datenmodellerweiterung erstellen, die zusätzliche Informationen zu einem Konzept auflistet, das bereits im Debugger vorhanden ist, erweitern Sie die vorhandenen Informationen, anstatt sie durch neue Informationen zu ersetzen. Anders ausgedrückt: Eine Erweiterung, die Details zu einem Modul anzeigt, sollte das vorhandene Module-Objekt erweitern, anstatt eine neue Liste von Modulen zu erstellen.
- Frei schwebende Hilfsprogramme müssen Teil des Debugger.Utility-Namespaces sein. Sie sollten auch entsprechend Unternamespaces sein (z. B. Debugger.Utility.Collections.FromListEntry).
Abwärtskompatibilität und breaking changes
Ein Skript, das veröffentlicht wird, sollte die Kompatibilität mit anderen Skripts, die davon abhängen, nicht unterbrechen. Wenn beispielsweise eine Funktion im Modell veröffentlicht wird, sollte sie nach Möglichkeit am gleichen Speicherort und mit den gleichen Parametern verbleiben.
Keine Verwendung externer Ressourcen
- Erweiterungen dürfen keine externen Prozesse erzeugen. Externe Prozesse können das Verhalten des Debuggers beeinträchtigen und sich in verschiedenen Remotedebuggerszenarien (z. B. dbgsrv-Remoten, ntsd-Remotezugriffe und "ntsd -d remotes") falsch verhalten.
- Erweiterungen dürfen keine Benutzeroberfläche anzeigen. Das Anzeigen von Elementen der Benutzeroberfläche verhält sich in Remotedebugszenarien falsch und kann Konsolendebugszenarien unterbrechen.
- Erweiterungen dürfen das Debuggermodul oder die Debugger-Benutzeroberfläche nicht über nicht dokumentierte Methoden bearbeiten. Dies führt zu Kompatibilitätsproblemen und verhält sich auf Debuggerclients mit unterschiedlicher Benutzeroberfläche falsch.
- Erweiterungen dürfen nur über die dokumentierten Debugger-APIs auf Zielinformationen zugreifen. Der Versuch, über Win32-APIs auf Informationen zu einem Ziel zuzugreifen, schlägt für viele Remoteszenarien und sogar für einige lokale Debugszenarien über Sicherheitsgrenzen hinweg fehl.
Keine Verwendung von Dbgeng-spezifischen Features
Skripts, die als Erweiterungen verwendet werden sollen, dürfen nach Möglichkeit nicht auf dbgeng-spezifischen Features basieren (z. B. das Ausführen von "klassischen" Debuggererweiterungen). Skripts sollten zusätzlich zu jedem Debugger verwendet werden können, der das Datenmodell hostet.
Testen von Debuggererweiterungen
Es wird erwartet, dass Erweiterungen in einer Vielzahl von Szenarien funktionieren. Während einige Erweiterungen für ein Szenario spezifisch sein können (z. B. ein Kerneldebuggingszenario), sollte erwartet werden, dass die meisten Erweiterungen in allen Szenarien funktionieren oder Über Metadaten verfügen, die die unterstützten Szenarien angeben.
Kernelmodus
- Live-Kerneldebuggen
- Debuggen des Kernelabbilds
Benutzermodus
- Debuggen im Livebenutzermodus
- Debuggen des Benutzermodusdumps
Berücksichtigen Sie außerdem diese Debuggerverwendungsszenarien.
- Debuggen mit mehreren Prozessen
- Debuggen mehrerer Sitzungen (z. B. Dump + Livebenutzer innerhalb einer einzelnen Sitzung)
Remotedebuggernutzung
Testen Sie den ordnungsgemäßen Betrieb mit den Remotedebuggerverwendungsszenarien.
- dbgsrv-Remotegeräte
- ntsd remotes
- ntsd -d remotes
Weitere Informationen finden Sie unter Debuggen mithilfe von CDB und NTSD und Aktivieren eines Prozessservers.
Regressionstests
Untersuchen Sie die Verwendung der Testautomatisierung, die die Funktionalität Ihrer Erweiterungen überprüfen kann, wenn neue Versionen des Debuggers veröffentlicht werden.
Weitere Informationen
Native Debuggerobjekte in JavaScript-Erweiterungen
Native Debuggerobjekte in JavaScript-Erweiterungen: Debuggerobjektdetails.