“托管调试器（如Visual Studio）的哪些版本可以调试哪些版本的CLR？怎么办？”
这是调试器版本控制的基本问题。
以下是从版本控制的角度来看的“调试堆栈”，包括每个层之间的协议和进程边界：
- 用户源代码协议：
由编译器处理的源语言。---编译器/调试对象进程边界---- - 正在调试的用户应用程序。
协议：IL操作码，元数据。这些都在ECMA标准中公开定义。 - 运行应用程序的CLR。(mscorwks.dll)协议：
专用CLR调试通信。---调试对象/调试器进程边界---- - CLR调试API（ICorDebug）(mscordbi.dll)
协议：公共ICorDebug API。这是一个高版本的COM经典API。 - 调试器，如visualstudio或MDbg。
协议：任意调试器扩展接口。也可能暴露ICorDebug。 - 调试器扩展、表达式计算器等。
所以这里可能有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应用程序的原因。