.NET组件中RuntimeVersion的作用是什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
成都创新互联公司是专业的弥渡网站建设公司，弥渡接单;提供成都网站设计、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行弥渡网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
使用过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。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。
