在.NET组件的注册表中，RuntimeVersion并不直接决定组件运行的CLR版本。实际上，无论组件的RuntimeVersion设置为何，当前系统中的最新CLR版本会被加载。当尝试创建不同RuntimeVersion的.NET类型时，由于同一进程不支持多个CLR版本，可能导致失败并返回REGDB_E_CLASSNOTREG。在.NET 4.0及以后，这种情况可能发生变化，允许进程内加载多个版本的CLR。
使用过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。如
最低0.47元/天 解锁文章
扫一扫
1761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
