Home/ Questions/Q 6079411
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T10:56:36+00:00

I’m using the following unmanaged C++ code to instantiate the CLR from an Excel

  • 0

I’m using the following unmanaged C++ code to instantiate the CLR from an Excel 2003 add-in (a COM shim for a .NET add-in):

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

and for the vast majority of the machines in our organisation (a few hundred) this works perfectly, even those with multiple CLR versions installed; however for a few machines a wrong (older) version of the CLR is instantiated which then fails to load the assembly as it requires the .NET 2 runtime.

Yesterday for the first time I ran Process Explorer and this was quite revealing showing the following on one of the problem machines:

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 has loaded the wrong version of the runtime even though a newer one is availble. Now I need to find out why.

A few possibilities that come to mind:

  1. There is something odd with the ‘priority’ of CLR instantiation on the specific machine, even though the MS docs (http://msdn.microsoft.com/en-us/library/ms231419.aspx) appear to indicate that you’ll always get the newest unless you request a specific version.
  2. Another add-in in Excel has already (deliberately) instantiated a .NET 1 CLR and Excel can’t host more than one.

I strongly suspect the second of these but don’t know how to prove / fix it.

Has anyone seen similar behaviour? Any suggestions on what is going on?

A few other notes:

  • All workstations are running Windows XP SP3
  • Excel 2003 SP3 is the only version of Excel in our organisation

I can’t change either of these so a newer Excel version is not an option.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is the infamous CLR version injection problem. This is the somewhat mild kind as opposed to the really nasty kind you get when you write a shell extension in .NET.

    Problem is that there was an add-in that loaded before yours and it asked for the 1.1 version of the CLR to be loaded. That’s where the buck stops, a process can have only one version of the CLR. You can ask for the 2.0.50727 version to be loaded in your CorBindToRuntimeEx() call, that’s the one you need for your add-in. But that will fail. Asking for the default version will succeed but now your add-in will fail to load.

    The ‘something mild’ angle is that you could technically change the order in which add-ins get loaded, ensuring that CLR 2.0 gets loaded first. Not actually sure how to do this. The add-in that requires 1.1 has reasonable odds of still working correctly. Ask at superuser.com if that’s what you want to do.

    There’s a long term solution, CLR version 4 supports in-process side-by-side versioning of the CLR. Not something that will help you right now.

    • 0