Как расширить отладчик Visual Studio с помощью оболочки IronPython?

Question

Сначала проблема, которую я пытаюсь решить: я отлаживаю приложение C #, которое имеет огромные графы объектов (например, построение информационных моделей, своего рода объектно-ориентированная САПР). Когда я достигаю точки останова, у меня обычно есть длинные списки объектов, которые мне сначала нужно преобразовать, чтобы они были полезны для отладки.

В коде я использую LINQ и лямбды для этого. Но вы не можете сделать это в окне Watch и в Immediate.

Как я могу добавить расширение оболочки IronPython в Visual Studio 2010, которое позволяет мне просматривать ту же информацию, что и в окне Immediate / в окне Watch?

РЕДАКТИРОВАТЬ: Я могу понять, как сделать визуализатор отладчика. Но из API кажется, что у меня будет доступ только к визуализируемому объекту, хотя я бы предпочел иметь доступ ко всем локальным переменным.

РЕДАКТИРОВАНИЕ: Из документации по msdn кажется, DE (Debug Engine) с EE (Expression Evaluator?) Может справиться с задачей. Это для интеграции вашего собственного языка в Visual Studio. Я пытаюсь подключиться к существующему DE или хотя бы предоставить свой собственный EE .

Answer 1

Оказывается, довольно просто написать надстройку для Visual Studio 2010: просто скачайте и установите Visual Studio 2010 SDK.Затем создайте проект Addin.

Метод OnConnection в классе Connect вашего Addin предоставит вам экземпляр DTE2.Это можно использовать для оценки в выражении отладчиков Visual Studio:

DTE2 application; // fill this in OnConnection
application.Debugger.GetExpression("some c# code goes here")

Результатами являются Expression экземпляры, COM-объекты.Проверьте свойство Value.

Домашнее задание: Подумайте, как обернуть это в красивую питоническую структуру, чтобы она выглядела цельно.

Answer 2

Не знаю, поможет ли это, но есть хорошая серия статей о написании отладчиков и расширений в управляемом коде по адресу:

http://devhawk.net/blog/2009/2/27/writing-an-ironpython-debugger-mdbg-101

Прежде чем я начну писатьЯ думаю, что любой код отладчика поможет быстро просмотреть доступную инфраструктуру отладчика .NET, а также проект отладчика командной строки MDbg.Пожалуйста, обратите внимание, что мое понимание этого материала довольно элементарно - Майк Сталл - «человек», если вы ищете для чтения блоггер отладчика .NET.

CLR предоставляет ряд неуправляемых API для таких вещей, какразмещение CLR, чтение и запись метаданных CLR и - что более актуально для нашего текущего обсуждения - отладка, а также чтение и запись символов отладчика.Эти API представляются как COM-объекты.API отладки CLR позволяет вам делать все то, что вы ожидаете сделать в отладчике: присоединение к процессам (фактически, доменам приложений), создание точек останова, пошаговый код и т. Д. Конечно, будучи неуправляемым API, это в значительной степени недоступно для использования из IronPython.К счастью, MDbg оборачивает этот неуправляемый API для нас, делая его доступным для любого управляемого языка, включая IronPython.

Базовый дизайн MDbg выглядит следующим образом:

image

Atвнизу находится «сырая» сборка, которая содержит определения C # неуправляемого API отладчика - в основном все, что начинается с ICorDebug и ICorPublish.Raw также определяет некоторые API метаданных, поскольку именно так информация о типах предоставляется отладчику.

Следующий уровень - сборка «corapi», которую я называю низкоуровневым API управляемого отладчика.Это довольно тонкий слой, который переводит неуправляемую парадигму в нечто более приятное для разработчиков управляемого кода.Например, перечислители COM, такие как ICorDebugAppDomainEnum, представляются как типы IEnumerable.Кроме того, интерфейс управляемого обратного вызова отображается как события .NET.Он не идеален - код написан в стиле C # 1.0, поэтому нет обобщений или выходов.

Где corapi - это низкоуровневый API, «mdbgeng» - это высокоуровневый API-интерфейс управляемого отладчика.Как и следовало ожидать, он оборачивает низкоуровневый API и обеспечивает автоматическую реализацию общих операций.Например, этот слой поддерживает список точек останова, поэтому вы можете создать их до загрузки соответствующей сборки.Затем, когда сборки загружены, они проходят через список несвязанных точек останова, чтобы посмотреть, можно ли их связать.Также этот слой автоматически создает основную точку останова точки входа.

Наконец, наверху у нас есть само приложение MDbg, а также любые расширения MDbg (обозначенные ... на диаграмме выше).Сборка mdbgext определяет типы, общие для MDbg.exe и сборок расширения.У MDbg есть несколько классных расширений - включая расширение IronPython - но сейчас я сосредоточен на создании чего-то настолько легкого, насколько это возможно, поэтому я собираюсь отказаться от механизма расширяемости, по крайней мере, на данный момент.

Мой первоначальныйПрототип был написан против API высокого уровня.Было два проблемы с этим подходом.Во-первых, в API высокого уровня отсутствует поддержка Just My Code.Как я упоминал в своем последнем посте, поддержка JMC имеет решающее значение для этого проекта.Добавление поддержки JMC не сложно, но я пытаюсь внести как можно меньше изменений в исходный код MDbg, поскольку я не заинтересован в разветвлении и поддержке этого кода.Во-вторых, в то время как низкоуровневый API предоставляет основанный на событиях API (OnModuleLoad, OnBreakpoint, OnStepComplete и т. Д.), Высокоуровневый API обеспечивает более ориентированный на консоль API циклического выполнения.Я обнаружил, что управляемый событиями API более понятен для работы, и я думаю, что он будет работать лучше, если я когда-нибудь создам версию ipydbg с графическим интерфейсом.Поэтому я решил работать против низкоуровневого API (aka corapi).

Я упоминал выше, что не хочу менятьИсточник MDbg, но я сделал одно небольшое изменение.Разделение corapi и raw на две отдельные сборки является устаревшим артефактом более ранней версии MDbg.Поэтому я решил объединить эти два в одну сборку под названием CorDebug.Кроме простой очистки атрибутов уровня сборки, чтобы сделать возможной одну сборку, я вообще не изменил исходный код.