MSCOREE.DLL ?

Oct 8, 2013 at 8:28 PM
When I load my ExcelDNA addin (XLL), it loads and runs fine.

However, in Excel, under Excel Options, Addins list, I see two references to my addin:

First Addin has the name "MyAddin" and the location shows the full path and name of the MyAddin.XLL file and the Type says "Excel Add-in".

Second Addin also has the name "MyAddin" but the location says "mscoree.dll" and the Type says "COM Add-in"

Why mscoree.dll? And can I change this refer to the actual DLL?
Coordinator
Oct 8, 2013 at 8:39 PM
Edited Oct 8, 2013 at 8:40 PM
Hi Ismail,

Behind the scenes, Excel-DNA loads a COM add-in in Excel to support the ribbon. So having the two entries is normal.

Usually you'll see no Location entry for the COM Add-In. I suspect you have registered the add-in somehow - perhaps by having had the Register for COM Interop checkbox on in the Visual Studio project, or as part of some installer.

Anyway, the mscoree.dll is the main .NET runtime library. For regular COM components that you implement with .NET, the registration is always against this library. So I think you'll find that when running your add-in on a fresh machine you'll have nothing in the Location: information.

-Govert
Oct 10, 2013 at 2:37 PM
Exactly... In a clean machine, the location shows nothing, exactly as you described. :)

With the mscoree.dll, I was actually more concerned about possible clashes with other addins if something goes wrong in my addin or in any other addin. I know every addin uses the same mscoree.dll (unless they are shimmed) and if one of the addins misbehave or crash, that might effect all others as well.

I actually shimmed my DLL before ExcelDNA using Microsoft's COM Shim Wizard and the method worked very nicely.
That empty Location information also pointed at the correct path and name of the DLL as well; and I was able to isolate my DLL from the others.

But with ExcelDNA in place, I do not have to register my DLL anymore which is great - but if I go back to shimming, I'll have to mess with the admin rights again in order to register which is really a headache. Additionally, I have to shim both 32-bit and 64-bit versions of my DLL separately and I don't even know how that'll work out; the shimming wizard might have to be compiled for 64-bit maybe. Anyway, I don't really want to go back to shimming for now. Just like Microsoft solved the DLL hell with .NET, I wish they could do something with this mscoree.dll hell !
Coordinator
Oct 10, 2013 at 2:45 PM
Hi Ismail,

Effectively the Excel-DNA stuff is all 'shimmed' already.
Excel-DNA loads the add-in into a separate AppDomain, and the .xll acts as the native wrapper for the COM library. I think you got the mscoree.dll registered somehow during the development, by having Visual Studio register your add-in library.

Even in the cases where the Excel-DNA add-in is persistently registered, (e.g if you want to use COM classes from the add-in directly in VBA) then the .xll is registered as the COM InProcServer32.

-Govert
Oct 10, 2013 at 7:34 PM
Something new I learned. The "already shimmed" feature is a big plus.
Wonderful !!
Thanks for this great tool Govert.
And thanks for such quick responses.