“托管调试器(如Visual Studio)的哪些版本可以调试哪些版本的CLR?怎么办?”


这是调试器版本控制的基本问题。


以下是从版本控制的角度来看的“调试堆栈”,包括每个层之间的协议和进程边界:

  1. 用户源代码协议:
    由编译器处理的源语言。---编译器/调试对象进程边界----
  2. 正在调试的用户应用程序。
    协议:IL操作码,元数据。这些都在ECMA标准中公开定义。
  3. 运行应用程序的CLR。(mscorwks.dll)协议:
    专用CLR调试通信。---调试对象/调试器进程边界----
  4. CLR调试API(ICorDebug)(mscordbi.dll)
    协议:公共ICorDebug API。这是一个高版本的COM经典API。
  5. 调试器,如visualstudio或MDbg。
    协议:任意调试器扩展接口。也可能暴露ICorDebug。
  6. 调试器扩展、表达式计算器等。

所以这里可能有6个不同的组件可以被版本化!


加载哪个CLR?


生成一个单独的进程,它将在一个单独的进程中执行。

加载的CLR版本由shim/loader/config策略确定。调试器在这里是不可知的,尽管它确实可以做一些事情来影响这一点,比如在启动应用程序之前放置配置文件。由于托管可执行文件是IL操作码和元数据,这些都是经过很好指定的,因此有一些版本控制选项可用于编译.NET版本X的应用程序,但在.NET版本Y上运行它。例如,为.NET 1.1编译的应用程序可以在.NET 2.0上运行。

加载哪个ICorDebug?

一旦CLR版本(mscorwks.dll)确定后,下一个问题变成:调试器加载哪个mscordbi?


我们选择在ICorDebug而不是专用协议上对调试进行版本设置:

-ICorDebug已经是一个公共的comapi,并且已经通过像QueryInterface这样的东西来进行版本控制。

-这减少了测试组合。允许混合和匹配mscorwks.dll一个武断的mscordbi.dll会产生一个不断增长的测试矩阵。如果mscordbi.dll如果需要能够调试mscorwks的多个版本,它的复杂性将不断增加。

-这使得CLR可以在私有CLR调试协议上自由创新。它的一个优点是,它允许我们调整协议的聊天时间。


结果就是mscordbi.dll必须选择以匹配的版本mscorwks.dll那是装的。这是在第一次通过CreateDebuggingInterfaceFromVersion创建ICorDebug对象时完成的。

ICorDebug


调试器通常需要是最新版本,以便能够理解它在调试对象中看到的内容。例如,在V2中添加了泛型。V1.1调试器很难在V2应用程序中看到泛型。现在,关于是否可以通过“优雅的降级”来缓解这种混乱,通常是通过:

-让调试器忽略它不理解的内容(例如,不要在调用堆栈中显示泛型方法)

-构造一个近似的V2。

有时这些技术可以奏效,但这是一个非常滑的斜坡。
这就是VS2003无法调试.NET2.0应用程序的原因。

 

标签: none

添加新评论