none
Shimming an Add-in that exposes objects to Excel VBA RRS feed

  • Question

  • My shared VB.Net 2010 based Excel add-in exposes a number of objects to VBA. Will shimming it cause problems with the way VBA creates instances of these objects?

    I have just finished shimming an Outlook add-in with the VS 2010 Shim Wizard. I believe I understand what's going on now so it's time to shim my Excel add-in. During this process, I noticed I had a couple of forms that were declared as public (I have since made them Friends) but I noticed that the HKCR\CLSID entries for them were still pointing to mscoree.dll. I assume that the self-registration process set these items up.

    If I remember correctly, all of the objects in my Excel add-in that are usable by VBA are declared as Public and so I expect that they too will end up pointing to mscoree.dll and not my shim dll. I'm sure I'm missing something here but is there something I have to do to make these entries point to the shim dll as opposed to mscoree.dll?

    I have just finished converting the Excel COM add-in from VB6 to VB.Net 2010 and boy are my arms tired!

    Thanks.


    • Moved by Cindy Meister MVPModerator Saturday, June 25, 2011 1:40 PM not using VSTO technology (From:Visual Studio Tools for Office)
    Friday, June 24, 2011 10:17 PM

Answers

  • Hi Ou8,

    >>but I noticed that the HKCR\CLSID entries for them were still pointing to mscoree.dll  I'm sure I'm missing something here but is there something I have to do to make these entries point to the shim dll as opposed to mscoree.dll?

    Based on my experience, it is normal scenario that the HKCR\CLSID entries still point to mscoree.dll. After creating and building a shared addin through the wizard, the addin will point to the mscoree.dll. I have tested on my side and from the Excel AddIn list, the COM AddIn all point to the mscoree.dll.

    In addition, please refer to this article:

    http://msdn.microsoft.com/en-us/magazine/cc301485.aspx

    which introduces the details about mscoree.dll:

    "To allow native and managed code to coexist, some mechanism is needed to allow managed code executing inside of the CLR (MSCOREE.DLL) to integrate with code running outside of MSCOREE.DLL. This means that managed programs need to run in "unmanaged mode" long enough to execute classic COM or Win32-based code. Also, unmanaged threads may need to visit MSCOREE.DLL long enough to be able to invoke a method on a managed type."

    Hope you  can figure out about this.

    Best Regards,


    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Bruce Song Friday, July 8, 2011 12:29 PM
    Tuesday, June 28, 2011 9:05 AM