Friends who have used com to access the. NET component should note that there is a runtimeversion key value in the corresponding registry:
The runtimeversion name can easily be mistaken for runtimeversion to specify the CLR version that the. NET component should run. In fact, the meaning of this key value is not particularly consistent with that on the word. If we consider a situation: first, the process first creates. net Type instance, runtimeversion is marked as 1.1, and then create.. Net instances whose runtimeversion is marked as V2.0. What CLR versions will be loaded? In fact, in the current. net version (excluding Silverlight), because it cannot support loading multiple CLR versions in the same process, it cannot support loading different CLR versions according to runtimeversion. In fact, CLR always loads the latest CLR version (strictly speaking, it is mscoree. dll ). Therefore, in the previous case, if 1.1 and 2.0 are installed on the machine, the process actually only loads the 2.0 CLR instead of the 1.1. If there is only 1.1 on the machine, the first 1.1. net will be created successfully, and the CLR of 1.1 will be started, and the second of 2.0. net Type will fail to be created, and return regdb_e_classnoregulatory (0x80040154)
To sum up, when a. Net instance is created through the cocreateinstance of COM, the CLR always loads the latest CLR version. If the startup is successful, check whether the CLR version is greater than or equal to the runtimeversion key value. If yes, success, s_ OK is returned; otherwise, regdb_e_classnoregulatory is returned. Therefore, if you find that regdb_e_classnoreg is returned during cocreateinstance, but the registry is normal, check runtimeversion.
By the way. in. Net 4.0, we are working on removing the restriction that different versions of CLR cannot be loaded in the process. It is very likely that the runtimeversion behavior will change accordingly, but there are still some details not finalized yet, I will update the message as soon as possible.