使用过COM来访问.NET组件的朋友们应该都会注意到在对应注册表中有一个RuntimeVersion的键值：
这个RuntimeVersion的命名很容易让人误认为RuntimeVersion是用来指定该.NET组件所应该运行的CLR的版本号。实际上，这个键值的意思和字面上不是特别一致。如果我们考虑一个情况：首先，进程中先创建一个.NET类型的实例，RuntimeVersion标记为1.1，然后再创建一个.NET类型的实例，其RuntimeVersion标记为v2.0，那么到底会加载那些CLR版本呢？其实，在目前的.NET版本（Silverlight除外）中，因为无法支持在同一个进程中加载多个不同版本的CLR，因此无法支持真正的按照RuntimeVersion来加载不同的CLR版本。实际上，CLR总是加载最新的CLR版本（严格来说其实是mscoree.dll来加载）。因此，在之前的情况下，如果机器上面安装了1.1和2.0，实际上进程只加载了2.0的CLR，而没有加载1.1。如果机器上面只有1.1的话，第一个1.1的.NET会创建成功，并且启动1.1的CLR，第二个2.0的.NET类型会创建失败，并且返回REGDB_E_CLASSNOTREG (0x80040154)
总结一下：通过COM的CoCreateInstance创建.NET类型的实例的时候，CLR总是加载最新的CLR版本，如果启动成功，检查该CLR版本是否大于或等于RuntimeVersion键值。如果是，成功，返回S_OK，否则失败，返回REGDB_E_CLASSNOTREG。因此，如果在CoCreateInstance的时候发现返回REGDB_E_CLASSNOTREG，但是注册表又没有问题的话，不妨检查一下RuntimeVersion。
顺便说一句，在.NET 4.0中，我们正在着手去掉进程内无法加载多个不同版本CLR的限制，很有可能RuntimeVersion的行为也会作出相应改变，但是目前还有一些细节没有敲定，等有了进一步消息我会尽快更新。
