none
Addin Load Failed

    Question

  • Hi All,

    I am having an XLA addin and XLAM addin (2007 support).

    My XLA addin is loaded first to Excel which loads my C# Managed code through COMShim addin approach.

     

    Now to support Office 2007 ribbon we have created the XLAM add-in which has the ribbon UI.

     

    I am trying to load the ribbon add-in if user is having excel 2007 and heigher otherwise my code gets executed.

     

    I have a loadribbon method which does the ribbon as follows:

     

      if (Convert.ToDecimal(xlApp.Version) >= 12)

                {

                    Excel.Workbook excelWorkbook = xlApp.Workbooks.Open(filePath, 0,

                                                                       false, 5, "", "", false, Excel.XlPlatform.xlWindows,

                                                                     "\t", true, false, null, true);

    }

     

     

    Now we found that as it is a workbook open (To loading we are loading one xlam workbook)method we will not follow this approach and we ll modify the XLAM add-in load using Excel application addin load as follows

     

     

                    xlApp.AddIns.Add(filePath, true);

                    xlApp.AddIns.get_Item("myribbon").Installed = true;

     

     

    But i am getting exception while loading the xlam add-in using above code:

    Exception is :System.Runtime.InteropServices.COMException (0x800A03EC): Add method of AddIns class failed

     

    Can anybody help me solving this error.

     

     

     


    Dwipayan Das
    Tuesday, November 02, 2010 7:34 AM

Answers

  • Gentlemen, the solution is due to the context in which the AddIns.Add method is invoked.  Dwipayan is invoking it from within auto_open of the VBA add-in which is marshalled to the C# assembly.  If Dwipayan adds a timer and invokes AddIns.Add when the Timer::Tick is invoked, then the COM exception is not thrown.

    This issue has nothing to do with C# or VBA as I've been able to reproduce it in both environments.

    • Marked as answer by Dwipayan Das Friday, November 05, 2010 1:50 AM
    Thursday, November 04, 2010 7:46 PM

All replies

  • You'd get that error if say the file name was incorrect, though of course there could be other reasons. Try similar in Excel VBA, simply

    Application.AddIns.Add filePath

    Regards,
    Peter Thornton

    Tuesday, November 02, 2010 10:58 AM
  • Hi Peter,

     

    I am validating the (.xlam) file to be existing or not before trying to add the add-in file to the excel application addin list.

     

    2) I am also making sure one workbook is available before loading the add-in.I have modified my code slightly.

    AS:

                    Excel.Workbook xlWb = xlApp.Workbooks.Add(System.Type.Missing);               

                    xlApp.AddIns.Add(filePath, true);

                    xlApp.AddIns.get_Item("myribbon").Installed = true;

    3) One approach seems to be working for me is , copying my .xlam  from my default install location to \ users application Data\Microsoft\Addin\ folder and making the installed property to true while calling the loadribbon method.

    But still wondering why my Addin.Add() approach is not working. (Do i need to digitally sign my xlam addin so it can pass the Office 2007 security policy for 3rd party add-in and Macros.

     

    Thanks for your suggestion.

    Still scratching my head. :)

     


    Dwipayan Das
    Tuesday, November 02, 2010 12:49 PM
  • It looks like only the .Addins.Add line is failing, so only try only testing one thing at a time. Generally it's easier to test this sort of thing in VBA as I suggested.

    Placing the addin in a default addins folder makes it more convenient for the user to install/uninstall the addin. Also the default addin folder is typically marked as a 'Trusted location' which means code will work with a higher level of security. However it's not necessary to put it in the addins folder, it should work fine from say my Documents.  So I can't explain why putting it there appears to solve the problem.

    Somewhat similar to "trusted location", digitally signing a project may allow it run with a higher macro security level. However it's not necessary to sign it (subject security settings).

    I don't think security setting will affect whether or not the addin can be added to the collection, merely whether or not it loads. But I might be wrong, try lowering your security to a minimum (for testing)

    Regards,
    Peter Thornton

    Tuesday, November 02, 2010 1:08 PM
  • Hi Perter,

    I moved the install logic to VBA Code (.xla) which loads my .xlam addin and it is working fine ,But still no luck with C# managed code.

    VBA Code Working fine :)

    Sub InstallAddIn()

            Dim myaddin As Excel.AddIn

            Dim addinPath As String

            addinPath = Application.AddIns.Item("myxlaaddin").Path

            Application.Workbooks.Add

            Set myaddin = Application.AddIns.Add(Filename:=addinPath & "\myRibbon.xlam")

            myaddin .Installed = True

        End Sub

    C# Managed code which fails as follows :

                Excel.Workbook xlWb = xlApp.Workbooks.Add(Missing.Value);                

                xlApp.AddIns.Add(filePath, true); //Throws COM Exception.

                xlApp.AddIns.get_Item("myxlribbon").Installed = true;

    Note:My requirement is to load the add-in inside the managed code.

    Can you please try the same and let me know if you get any success to it.

    Thanks 

     


    Dwipayan Das
    Thursday, November 04, 2010 1:26 PM
  • Did you try what I suggested before.

    I don't really understand what you are trying to do. Why are you attempting to install the addin in VBA and C#, normally it's a one off operation. Where is InstallAddIn(), when does that get called.

    Could you explain the objective.

    Regards,
    Peter Thornton

    Thursday, November 04, 2010 3:49 PM
  • The AddIns.Add method works if invoked after the auto_open sub-routine invocation.  This is irrespective of the Add method called from VBA or C#.  To workaround this restriction use a Windows.Form.Timer that is invoked only once and place the initialization logic in the Tick handler.

    Thursday, November 04, 2010 4:02 PM
  •  

    I have 2 add-ins currently one X.xla and other newly introduced to support Office 2007 and heigher i.e X.XLAM

     

    X.xla is loaded into excel when excel is launched and loads the Managed c# code and build the toolbar (For office v < 2003)

    For office 2007 we need to load the XLAM addin which loads the Ribbon UI .

    So load/adding of xlam add-in can be done at the X.XLA macro code level  or can be called from C# managed code (Which is not working for me right now ).

    The InstallAddIn() is working fine at VBA but if i try to do it from C# it fails.

    My Requirement is we should avoid the add-in load in the VBA code and do it in managed code.

    Hope you are able to follow me.Let me know if you need more clarifications.

    Thanks

     

     


    Dwipayan Das
    • Edited by Dwipayan Das Thursday, November 04, 2010 4:32 PM typo
    Thursday, November 04, 2010 4:32 PM
  • When you say "add-in load", do you mean "load" the xla/m file same as load a normal workbook, or do you mean add it to the addins collection, and install it such that in future it opens automatically when Excel starts.

    As regards to the Ribbon UI, is that for callbacks to the xlam or to the C# code. If the former, it's best managed with VBA in the addin, with the relevant xml packed in the xlam. FWIW no need for the addin to be added to the addins collection, that's a separate issue, and something that only needs to be done once.

    Regards,
    Peter Thornton

    Thursday, November 04, 2010 5:08 PM
  •  

    Previously we were doing it using the WorkBooks.Open(XLAMPath ) ----> But this approach is bad as we can always see the .xlam file shown in the recently opened document.

    So we have to add the xlam addin to the addin collection as a application level add-in.so we opt for addin it in the managed code but it didn't happen so we moved the adding task to be done at vba code.

     

    Yeah , there are some callback happening for the RibbonUI as well as we have used some Toogle buttons controls.

    Thanks


    Dwipayan Das
    Thursday, November 04, 2010 5:26 PM
  • Sorry I'm still not following -

    Previously we were doing it using the WorkBooks.Open(XLAMPath ) ----> But this approach is bad as we can always see the .xlam file shown in the recently opened document.

    Strange, I just tried that and it neither shows in Excel's recent file list nor on the start menu's recent documents list.

    So we have to add the xlam addin to the addin collection as a application level add-in.so we opt for addin it in the managed code but it didn't happen so we moved the adding task to be done at vba code.

    How often are you attempting to add the xlam to the addins collection, surely not every time the addin loads.

    Yeah , there are some callback happening for the RibbonUI as well as we have used some Toogle buttons controls.

    Do you mean callbacks to the VBA addin, or directly to your C# addin, or something else.

    Regards,
    Peter Thornton

    Thursday, November 04, 2010 5:46 PM
  •  

    1) We did the WorkBooks.Open (xlam path) inside the managed code.

     

      As we are opening a workbook every time , I am sure it has to show in the recent opened file.Are you calling the workbook open from managed code.

     

    2 ) You are correct it loads only once . So you are suggesting me to call the addIn.Add() in the VBA macro.

     

    3) The scenario is again tricky :We are using a Toogle button for Login/LogOff

         OnClick of Login button -> Logon window opens (Managed code) Here event is  raised from the RibbonUI --> VBA ---> C#

         Onsuccessfull Login Managed code does a callback to the XLAM macro to change the button caption/imageISO to LogOff.

     

    So its basically a callback from C# --> Managed through Application.Run(XLAM MacroName())

    Thanks

     


    Dwipayan Das
    Thursday, November 04, 2010 5:57 PM
  • 1) We did the WorkBooks.Open (xlam path) inside the managed code.
    As we are opening a workbook every time , I am sure it has to show in the recent opened file.Are you calling the workbook open from managed code.

    No, I've only tried in VBA, say
    Application.Workbooks.Open sFile

    I'm surprised it's different with managed code but I accept what you say.

    2 ) You are correct it loads only once . So you are suggesting me to call the addIn.Add() in the VBA macro.

    I wonder if there is some confusion here. An addin only needs to be added to the addins collection as a one time operation. Typically that's done by the user via the UI, though it can also be done by an installer (requires quite complicated registry stuff), and it can also be done in VBA or any other code that references Excel (it's not the most reliable way though).

    The point is, adding the addin to the addins collection AND setting it's .Installed property to true means the addin will load automatically when Excel starts. Whether or not the addin is in the the addins collection is irrelevant to the overall functionality of the addin. The addin can just as well be manually loaded by the user or some other code, eg.xlApp.Workbooks.open(sFile). Thereafter anything that needs to be done in its open event (say in 2003 add commandbars etc) or the Riboon UI stuff works exactly the same.

    3) The scenario is again tricky :We are using a Toogle button for Login/LogOff

    OnClick of Login button -> Logon window opens (Managed code) Here event is raised from the RibbonUI --> VBA ---> C#

    Onsuccessfull Login Managed code does a callback to the XLAM macro to change the button caption/imageISO to LogOff.

    So its basically a callback from C# --> Managed through Application.Run(XLAM MacroName())

    So are you saying the callback is intended to trigger code in the C# ,which in turn calls Application.Run(etc). Why not include all the relevant xml in the C# addin to which I take it also have the necessary callback stubs. I'm confused about this, though I accept it may not be related to the main issue.

    Regards,
    Peter Thornton

    Thursday, November 04, 2010 7:20 PM
  • Gentlemen, the solution is due to the context in which the AddIns.Add method is invoked.  Dwipayan is invoking it from within auto_open of the VBA add-in which is marshalled to the C# assembly.  If Dwipayan adds a timer and invokes AddIns.Add when the Timer::Tick is invoked, then the COM exception is not thrown.

    This issue has nothing to do with C# or VBA as I've been able to reproduce it in both environments.

    • Marked as answer by Dwipayan Das Friday, November 05, 2010 1:50 AM
    Thursday, November 04, 2010 7:46 PM
  • Gentlemen, the solution is due to the context in which the AddIns.Add method is invoked. Dwipayan is invoking it from within auto_open of the VBA add-in which is marshalled to the C# assembly. If Dwipayan adds a timer and invokes AddIns.Add when the Timer::Tick is invoked, then the COM exception is not thrown.

    I wasn't aware of that and thanks (not that I understand why that should be the case - although apparently related the addin and adding it to the collection are not). However, I don't think Dwipayan needs to add the addin to the addins collection more than once, rather than every time the addin is loaded. But I may be misunderstanding something.

    Regards,
    Peter Thornton

    Thursday, November 04, 2010 8:03 PM
  • Thanks 

    Timer worked for me.

     

     


    Dwipayan Das
    • Edited by Dwipayan Das Monday, November 08, 2010 12:30 PM No reason
    Monday, November 08, 2010 11:05 AM