小编Joh*_*kup的帖子

我正在使用以下非托管C++代码从Excel 2003加载项(用于.NET加载项的COM填充程序)实例化CLR:

    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版本.

我有一个XLA文件,将作为Excel加载项部署到组织中的许多用户.我的目的是将其部署到"Application Data\MyCompany"中用户的"文档和设置"文件夹中的目录.(事实上​​,这一切都是通过一个包装器来完成的,该包装器在本地复制最新版本的XLA并将其安装为Excel加载项).

但是,如果用户创建引用此XLA中定义的函数的工作表,则Excel似乎在函数调用中存储XLA的绝对路径.因此,如果用户将表单发送给同事,则Excel无法解析该功能,因为他们的XLA副本位于不同的绝对路径上(因为他们的用户名是绝对路径的一部分).

到目前为止,我的信念是Excel"只是应对",只要XLA作为插件安装,但事实并非如此.

是否真的需要为所有用户强制执行加载项的相同绝对路径？这在单个组织中是可能的,但我真的不能相信这是真的,因为它严重阻碍了XLS文件的共享.

谢谢.