如何使用IronPython外壳扩展Visual Studio调试器?

事实证明,编写一个VisualStudio2010插件相当简单:只需下载并安装VisualStudio2010 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 所有物

作业: 想一想如何用一个好的Python框架将其包装起来,使其看起来天衣无缝。

我不知道这是否会有帮助,但下面有一个关于在托管代码中编写调试器和扩展的好系列:

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

在我开始编写任何调试器代码之前,我认为 快速回顾这篇文章。NET调试器基础结构,可作为 以及MDbg命令行调试器的设计。请注意,我的 对这些东西的理解相当初级——迈克·斯泰尔是——达 如果你在找一个。NET调试器博主阅读。

CLR为托管之类的事情提供了一系列非托管API CLR,读写CLR元数据,与我们的 当前讨论调试以及读写调试程序 符号。这些API作为COM对象公开。CLR调试API 允许你做所有你希望能做的事情 在调试器中执行:附加到进程(实际上是应用程序域),创建 断点、单步代码等。当然,作为非托管API, 它几乎无法从IronPython中使用。幸运的是,MDbg 为我们包装此非托管API,使其可供任何托管API使用 语言,包括IronPython。

MDbg的基本设计如下所示:

形象

底部是原始组件,其中包含C#定义 对于非托管调试器API,基本上是以 ICorDebug和ICorPublish。Raw还定义了一些元数据API, 因为这就是类型信息向调试器公开的方式。

下一层是corapi组件,我称之为 低级托管调试器API。这是一个相当薄的层 将非托管模式转化为更受欢迎的模式 托管代码开发人员。例如,COM枚举器,例如 ICorDebugAppDomainEnum作为IEnumerable类型公开。还有 托管回调接口被公开为。网络事件。不是 完美代码是用C#1.0风格编写的,因此没有泛型 或者收益率。

corapi是低级API,mdbgeng是高级管理API 调试器API。正如您所料,它包装了低级API和 提供常见操作的自动实现。例如 该层维护断点列表,以便您可以创建它们 在加载相关程序集之前。然后当程序集 加载后,它会遍历未绑定断点的列表,查看是否有任何断点可以 受到约束。这一层也会自动创建主界面 入口点断点。

最后,在顶部,我们有MDbg应用程序本身,以及 任何MDbg扩展(由上图中的表示)。这个 mdbgext程序集定义MDbg之间共享的类型。exe和 扩展组件。MDbg有一些很酷的扩展,包括 IronPython扩展,但现在我专注于构建一些东西 尽可能轻量级,所以我将放弃可扩展性 至少目前是这样。

我最初的原型是根据高级API编写的。那里 这种方法有两个问题。首先是没有 在高级API中只支持我的代码。正如我在报告中提到的 最后一篇文章,JMC的支持对这个项目至关重要。添加JMC 支持并不难,但我正在尝试尽可能少的改变 致MDbg来源,因为我对分叉和 维护代码。第二,虽然低级API提供了 基于事件的API(OnModuleLoad、OnBreakpoint、OnStepComplete等) 高级API提供了更面向控制台的循环API。我发现 事件驱动的API应该更干净,而且我也这么认为 如果我能构建一个ipydbg的GUI版本,工作会更好。太过分了 决定对抗低级API(又名corapi)。

我在上面提到,我不想更改MDbg源代码,但我 确实做了一个小小的改变。把科拉皮和生肉一分为二 单独的程序集是早期版本的 MDbg。所以我决定把这两个组合成一个叫做 科迪布格。除了对程序集级属性进行一些简单的清理之外 为了使单个程序集成为可能,我没有更改源代码 完全