管理由CorBindToRuntimeEx加載的.NET CLR的版本是什麼？

Question

我使用下面的非託管C++代碼從Excel 2003外接實例的CLR（一個COM的.NET墊片外接）：

hr = CorBindToRuntimeEx(
     0, // version, use default 
     0, // flavor, use default 
     0, // domain-neutral"ness" and gc settings 
     CLSID_CorRuntimeHost, 
     IID_ICorRuntimeHost, 
     (PVOID*) &m_pHost); 

和絕大多數的機器在我們的組織中（幾百個），這個工作非常完美，即使是那些安裝了多個CLR版本的人也可以。然而，對於少數機器來說，CLR的錯誤（舊版本）版本會被實例化，然後無法加載程序集，因爲它需要.NET 2運行時。

昨天是第一次我跑的Process Explorer，這是很說明問題出在有問題的計算機下列操作之一：

process  pid type Handle or DLL 
-------  --- ---- ------------- 
procexp.exe 5056 DLL c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorworks.dll 
EXCEL.EXE 7180 DLL c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorworks.dll 

即Excel中加載了錯誤版本的運行時即使有更高一個是可用的。現在我需要找出原因。

浮現在腦海中有幾個可能性：

1. 有一些奇怪的與CLR實例化的特定機器上的「優先」，即使MS文檔（http://msdn.microsoft.com /en-us/library/ms231419.aspx）似乎表明你會永遠得到最新的，除非你請求一個特定的版本。
2. Excel中的另一個加載項已經（故意）實例化.NET 1 CLR，並且Excel不能託管多個。

我強烈懷疑其中的第二個，但不知道如何證明/修復它。

有沒有人看過類似的行爲？關於發生什麼事的任何建議？

其他一些注意事項：

• 所有工作站運行的是Windows XP SP3
• 的Excel 2003 SP3爲Excel在我們組織的唯一版本

我不能更改的這些更新的Excel版本不是一個選項。

Answer 1

這是臭名昭著的CLR版本注入問題。這是相當溫和的一種，而不是在.NET中編寫shell擴展時遇到的真正令人討厭的類型。

問題是有一個加載項在你的之前加載，它要求加載1.1版本的CLR。這就是降壓停止的地方，一個進程只能有一個版本的CLR。您可以要求在CorBindToRuntimeEx（）調用中加載2.0.50727版本，這是您加載項所需的版本。但那會失敗。詢問默認版本將成功，但現在您的加載項將無法加載。

'有點溫和'的角度是，你可以從技術上改變加載項的加載順序，確保CLR 2.0首先被加載。實際上並不確定如何做到這一點。要求1.1的加載項具有仍然正常工作的合理可能性。詢問superuser.com是否您想要做的事。

有一個長期的解決方案，CLR版本4支持CLR的進程內並行版本控制。不是現在可以幫助你的東西。

Answer 2

您可以使用GetCORVersion來檢查CLR是否已經被加載？如果GetCORVersion返回v1.x作爲加載的CLR版本，則中止加載CLR並向用戶顯示錯誤消息。

正在將您的加載項遷移到.net v4中嗎？ v4支持CLR（（v1.x或V2）和V4及更新版本）的進程內並行託管。看看CLRCreateInstance。

參考文獻：
CLR Hosting Overview
In-Process Side-by-Side @ MSDN Magazine