Как расширить Отладчик Visual Studio с помощью оболочки IronPython?
Сначала проблема я пытаюсь решить: я отлаживаю приложение C#, которое имеет огромные графы объектов (думайте, Создавая Информационные модели, своего рода объектно-ориентированный CAD). Когда я поразил точку останова, у меня обычно есть длинные списки объектов, которые я должен был бы сначала преобразовать, чтобы быть полезным для отладки.
В коде я использую LINQ и лямбды, чтобы сделать это. Но Вы не можете сделать этого в окне Watch и окне Immediate.
Как я мог пойти о добавлении, что IronPython окружает расширение Visual Studio 2010, который позволяет мне отследить ту же информацию, доступную окну Immediate / окно Watch?
Править: Я могу выяснить, как сделать отладчик visualizer. Но от API кажется, что у меня только был бы доступ к объекту визуализируемым - в то время как я на самом деле предпочту иметь доступ ко всем локальным переменным.
Править: Из документации относительно MSDN это кажется DE (Механизм Отладки) с EE (Средство анализа Выражения?) может добиться цели. Это для интеграции Вашего собственного языка в Visual Studio. Я пытаюсь сцепиться в существующий DE или по крайней мере обеспечить мой собственный EE.
2 ответа
Оказывается, написать надстройку для Visual Studio 2010 довольно просто: просто скачайте и установите Visual Studio 2010 SDK. Затем создайте проект Addin.
Метод OnConnection в классе Connect вашего надстройки предоставит вам экземпляр DTE2 . Это можно использовать для поиска в Средстве оценки выражений отладчиков Visual Studio:
DTE2 application; // fill this in OnConnection
application.Debugger.GetExpression("some c# code goes here")
Результатом являются экземпляры Expression , объекты COM. Проверьте свойство Значение .
Домашнее задание: Подумайте, как обернуть это красивым питоническим фреймворком, чтобы все выглядело безупречно.
Не знаю, поможет ли это, но есть хорошая серия статей о написании отладчиков и расширений в управляемом коде:
http://devhawk.net/blog/2009/2/27/writing-an-ironpython-debugger-mdbg-101
Прежде чем я начну писать код отладчика, я подумал, что будет полезно быстро просмотреть инфраструктуру отладчика .NET, которая доступна, а также а также дизайн отладчика командной строки MDbg. Пожалуйста, обратите внимание, что мое понимание этих вещей довольно рудиментарное - Майк Столл является "да человек", если вы ищете блоггер для отладчика .NET.
CLR предоставляет ряд неуправляемых API для таких вещей, как хостинг CLR, чтение и запись метаданных CLR и - что более актуально для нашей текущего обсуждения - отладка, а также чтение и запись отладочных символы. Эти API представлены в виде COM-объектов. CLR Debugging API позволяет вам делать все те вещи, которые вы ожидаете иметь возможность делать в отладчике: подключаться к процессам (фактически, доменам приложений), создавать точки останова, просматривать код и т.д. Конечно, будучи неуправляемым API, он практически недоступен для использования из IronPython. К счастью, MDbg оборачивает этот неуправляемый API для нас, делая его доступным для любого управляемого языку, включая IronPython.
Основной дизайн MDbg выглядит следующим образом:
image
Внизу находится "сырая" сборка, которая содержит определения 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 в высокоуровневом API. Как я уже упоминал в своем прошлом посте, поддержка JMC очень важна для этого проекта. Добавить поддержку JMC несложно, но я стараюсь внести как можно меньше изменений в исходный код MDbg, поскольку я не заинтересован в форке и поддерживать этот код. Во-вторых, хотя низкоуровневый API предоставляет API, основанный на событиях (OnModuleLoad, OnBreakpoint, OnStepComplete и т.д.), в то время как API высокого уровня предоставляет API высокого уровня предоставляет более ориентированный на консоль API циклов. Я нашел API, ориентированный на события, более чистым для работы, и я думаю, что он будет работать лучше, если я когда-нибудь создам GUI-версию ipydbg. Поэтому я решил работать с низкоуровневым API (aka corapi).
Выше я упоминал, что не хотел изменять исходники MDbg, но я все же сделал одно небольшое изменение. Разделение corapi и raw на две отдельные сборки является устаревшим артефактом более ранней версии MDbg. Поэтому я решил объединить их в одну сборку под названием CorDebug. Кроме некоторой простой очистки атрибутов на уровне сборки чтобы сделать единую сборку возможной, я не изменил исходный код вообще.