CorBindToRuntimeEx加载的.NET CLR版本受什么约束？ 我使用下面的非托管C++代码从Excel 2003的外接程序（C.S.M添加到.NET插件）中实例化CLR：

对于我们组织中的绝大多数机器（几百台），即使是安装了多个CLR版本的机器，这也能完美地工作；但是，对于一些机器，实例化了错误（较旧）版本的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

i、 e.Excel加载了错误的运行时版本，即使有更新的版本可用。现在我需要找出原因

我想到的几个可能性是：

特定机器上CLR实例化的“优先级”有些奇怪，即使MS文档(http://msdn.microsoft.com/en-us/library/ms231419.aspx)表示除非您要求特定版本，否则您将始终获得最新版本

Excel中的另一个外接程序已经（故意）实例化了.NET 1 CLR，Excel不能承载多个CLR 我强烈怀疑第二个问题，但不知道如何证明/修复它

有人见过类似的行为吗？有什么建议吗

其他一些注意事项：

• 所有工作站都运行Windows XP SP3
• Excel 2003 SP3是我们组织中唯一的Excel版本

我无法更改这两个版本，因此不能选择较新的Excel版本。

您可以用它检查CLR是否已加载吗？如果GetCORVersion返回v1.x作为加载的CLR版本，则中止加载CLR并向用户显示错误消息

是否可以将外接程序迁移到.net v4？v4支持进程内并行托管CLR（（v1.x或V2）和v4及更新版本）。看

参考资料：

---

这就是臭名昭著的CLR版本注入问题。这是比较温和的一种，而不是在.NET中编写shell扩展时所遇到的非常糟糕的一种

问题是在您之前加载了一个加载项，它要求加载CLR的1.1版本。这就是责任所在，一个进程只能有一个CLR版本。您可以要求在您的CorBindToRuntimeEx（）调用中加载2.0.50727版本，这正是您的外接程序所需要的版本。但这将失败。请求默认版本将成功，但现在加载项将无法加载

“温和”的角度是，您可以从技术上更改加载项的加载顺序，确保首先加载CLR 2.0。我不知道该怎么做。需要1.1的加载项仍能正常工作的几率是合理的。在superuser.com上询问你是否想这样做

---

有一个长期的解决方案，CLR版本4支持CLR的进程内并行版本控制。现在对您没有帮助。

看起来可能是这个问题：因此，可能这台机器有一个旧版本的VSTO。我将尝试确定这是否是问题所在。结果表明，机器确实安装了正确的VSTO，因此这不是问题所在。因此，这似乎越来越可能取决于Excel实例化外接程序的顺序，即一些以前加载的外接程序请求v1 CLR。

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