使用過COM來訪問.NET組件的朋友們應(yīng)該都會(huì)注意到在對應(yīng)注冊表中有一個(gè)RuntimeVersion的鍵值：

這個(gè)RuntimeVersion的命名很容易讓人誤認(rèn)為RuntimeVersion是用來指定該.NET組件所應(yīng)該運(yùn)行的CLR的版本號(hào)。實(shí)際上，這個(gè)鍵值的意思和字面上不是特別一致。如果我們考慮一個(gè)情況：首先，進(jìn)程中先創(chuàng)建一個(gè).NET類型的實(shí)例，RuntimeVersion標(biāo)記為1.1，然后再創(chuàng)建一個(gè).NET類型的實(shí)例，其RuntimeVersion標(biāo)記為v2.0，那么到底會(huì)加載那些CLR版本呢？其實(shí)，在目前的.NET版本（Silverlight除外）中，因?yàn)闊o法支持在同一個(gè)進(jìn)程中加載多個(gè)不同版本的CLR，因此無法支持真正的按照RuntimeVersion來加載不同的CLR版本。實(shí)際上，CLR總是加載***的CLR版本（嚴(yán)格來說其實(shí)是mscoree.dll來加載）。因此，在之前的情況下，如果機(jī)器上面安裝了1.1和2.0，實(shí)際上進(jìn)程只加載了2.0的CLR，而沒有加載1.1。如果機(jī)器上面只有1.1的話，***個(gè)1.1的.NET組件會(huì)創(chuàng)建成功，并且啟動(dòng)1.1的CLR，第二個(gè)2.0的.NET類型會(huì)創(chuàng)建失敗，并且返回REGDB_E_CLASSNOTREG (0x80040154)

總結(jié)一下：通過COM的CoCreateInstance創(chuàng)建.NET類型的實(shí)例的時(shí)候，CLR總是加載***的CLR版本，如果啟動(dòng)成功，檢查該CLR版本是否大于或等于RuntimeVersion鍵值。如果是，成功，返回S_OK，否則失敗，返回REGDB_E_CLASSNOTREG。因此，如果在CoCreateInstance的時(shí)候發(fā)現(xiàn)返回REGDB_E_CLASSNOTREG，但是注冊表又沒有問題的話，不妨檢查一下RuntimeVersion。

順便說一句，在.NET 4.0中，我們正在著手去掉進(jìn)程內(nèi)無法加載多個(gè)不同版本CLR的限制，很有可能.NET組件中RuntimeVersion的行為也會(huì)作出相應(yīng)改變，但是目前還有一些細(xì)節(jié)沒有敲定，等有了進(jìn)一步消息我會(huì)盡快更新。

【編輯推薦】

1. 使用C#輕松編寫.Net組件
2. .NET組件中的線程輔助
3. .NET組件和COM組件之間的相互操作
4. C#和VB.NET類型相關(guān)知識(shí)匯總
5. ASP.NET多附件上傳和附件編輯的實(shí)現(xiàn)