.NET Debugging API

PuerNoctis

Hallo Community,

kurz und prägnant:

Ich nutze in einer nativen C++ Applikation die DIA (Debug Interface Access) sowie DBGHELP Libraries um nach Auswertung von PDB Files in einem laufenden Prozess Debugger-ähnliche Dinge zu machen (z.B. Werte von Variablen on-the-fly ändern, oder die Adressen der Funktionen die gerade im Speicher des Prozesses geladen sind ausfinding zu machen und ausserhalb des normalen Programmflusses aufzurufen).

Gibt es hierzu ein äquivalent in Microsoft .NET? Die COM Interfaces um ICorDebug sehen sehr danach aus, weiß aber nicht, ob die alles können was ich brauche (ich gestehe mir ein, dass ich noch nicht vollständig durch die API geguckt habe). Mono bietet den Mono.Debugger.soft Namespace dafür an, der sich stark an die Java Debugging API orientiert.

Generell wäre es hilfreich zu wissen, ob man mit diesen ICorDebug Klassen einen Debugger für .NET Applikationen schreiben könnte, wie er z.B. im Visual Studio dabei ist. Nicht dass ich sowas vor hätte, Gott bewahre, aber wenn das gehen würde, wäre meine Anforderung sicherlich abgedeckt. Oder gibt es eine andere "Debugging API"? Und keine Sorge: Mir ist bewusst, dass die .NET VM anders handzuhaben ist wie ein nativer Prozess

Danke schon mal im Voraus für Eure Hilfe, und schöne Grüße!

PuerNoctis

Hallo,

mit ICorDebug gehts in die richtige Richtung. Hier findest du alles was dich interessieren sollte (Besonders im unteren Abschnitt die Verweise beachten).

PuerNoctis

Genial Zwergli! Danke für den Link! Genau so eine Beschreibung habe ich gesucht. Ich frage mich immernoch, wie ich diesen MSDN Artikel die ganze Zeit übersehen konnte

Mechanics

Darf ich fragen, was eure Anwendung in etwa macht? Hört sich reichlich kompliziert an ^^ Oder ist es nur so eine Art Game Trainer?

PuerNoctis

Nene, das nicht, also ich versuche jetzt nicht irgendwelche Games oder sonstigen Applikationen zu hacken ....wobei man es dafür vielleicht "mißbrauchen" könnte.

Ohne zu viel zu verraten:

Wir haben in einer Legacy Anwendung (C++/MFC) das Problem, dass wir keine vernünftigen automatisierten UI Tests erstellen können, da viele Informationen die man mit dem Auge normalerweise ablesen oder mit der Maus anklicken könnte, keine echten Controls sind die eigene Handles etc haben. Rührt daher, dass sehr viel direkt auf den Bildschirm gerendert wird, auch Labels etc. Letztendlich läuft halt viel auf Mouse-Pixel-Platzierung oder Bitmap-Vergleiche hinaus, aber wir wollen das definitiv datengetriebener gestalten. Refactoring des Codes ist durch hohes Coupling und schlechtes Design schon allein wegen des Aufwands ausser Frage (ca. 1 Mio. LOC!)

Anfangs hatten wir die Idee spezielle Funktionen einzubauen, die dann zur Laufzeit von unserer Testapplikation aufgerufen werden können, um an bestimmte Infos ran zu kommen, allerdings hieß es, dass code-changes erst mal aussen vor sind (was viiiiiiel einfacher für uns wäre).

Daher die Idee, dass wir uns wie ein Debugger verhalten und so unsere Werte direkt aus dem Speicher des Zielprozesses auslesen oder manipulieren. Mussten auch z.T. Assembler Calls injecten und ausführen lassen um Funktionen auszuwerten etc. War ne ziemliche Arbeit, aber es funktioniert genauso, wie sich es alle vorgestellt haben.

Unsere Probleme und die Lösung mögen immer noch nicht ganz klar sein vielleicht, ist aber auch ein riesen Topic dass ich nicht in ein paar Absätzen erklären kann, das muss man mal zeigen denke ich. Aber das wäre jetzt grob umrissen was wir da anstellen

....und wegen .NET frage ich deshalb, weil jetzt urplötzlich auch daran gedacht wird, das dafür zu machen.

EDIT: Vielleicht ein wenig knapper: Ziel ist es, interne Daten/Funktionen eines laufenden Prozesses zur Erhöhung der (automatisierten) Testbarkeit ohne Codechanges in der Zielapplikation von ausserhalb zu steuern. .NET würde ja gerade für UI z.B. Sachen Dinge wie die System.Windows.Automation Klassen bieten, wie es für das .NET Projekt super wäre - aber wie gesagt, es wird strikt darauf beharrt, dafür keinen Produktcode zu verändern

Wenn ich das lese, weiß ich nicht ob ich lachen oder heulen soll. Ist wieder so ein tpypischer Fall wo kein Mensch an die Testbarkeit denkt bei der Entwicklung und dann ne saftige Quittung für bekommt.

Das mit dem Testen von selbstgerenderten Zeugs ist natürlich schon nen Sonderfall. Aber für die Standardfälle würde ich nen Framework wie White verwenden.

Die zu testende Applikation muss nichts speziell implementieren - sowas macht testen nur leichter, aber es geht auch ohne Codeänderungen in den meisten Fällen.