Add-in load failure causes Excel to close immediately

[Backstop Solutions]

Hello,

I have a customer in production who is experiencing an issue loading the add-in. The issue seems environmental, but I'm hoping someone might have some insight into the issue so I can help them resolve.

First, only one user has reported the issue and another user at the company loaded successfully. We are using 0.33.9. 

When the user attempts to register the add-in, we see the ExcelDNA error log open and excel closes immediately. In order to get Excel to open, we need to delete the .xll from where it is being referenced.

I enabled trace logging on the add-in and see the following issues in the log:

ExcelDna.Integration Warning: 1 : GetExcelAddIns CreateInstance problem for type: Backstop.UI.AddInImplementation.RibbonAddin - exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'Backstop.UI.AddInImplementation.AddinScope' threw an exception. ---> ExcelDna.Integration.XlCallException: Exception of type 'ExcelDna.Integration.XlCallException' was thrown. at ExcelDna.Integration.XlCall.Excel(Int32 xlFunction, Object[] parameters) at ExcelDna.Integration.ExcelDnaUtil.GetApplication() at ExcelDna.Integration.ExcelDnaUtil.get_Application() at Backstop.UI.AddInImplementation.ExcelModule.Load() at Ninject.KernelBase.Load(IEnumerable`1 m) at Backstop.UI.AddInImplementation.AddinScope..cctor() --- End of inner exception stack trace --- at Backstop.UI.AddInImplementation.RibbonAddin..ctor() --- End of inner exception stack trace --- at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at ExcelDna.Integration.AssemblyLoader.GetExcelAddIns(ExportedAssembly assembly, Type t, Boolean loadRibbons, List`1 addIns)

The above is logged as a WARN and the registration continues, but considering our ribbon implementation fails to load, I'm guessing this is relevant. Considering the exception is invocation related, my first thought is that they have issues with the PIA assemblies for their version of excel. I recommended an uninstall/reinstall and the client was resistant to do so. 

The other error in the logs happens in autoopen:

ExcelDna.Integration Verbose: 1 : Enter Integration.DnaLibraryAutoOpen ExcelDna.Integration Verbose: 3 : Register RegistrationInfo - XllPath=C:\BackstopExcel\BackstopToolkit-packed64.xll, ProcName=RegistrationInfo, FunctionType=QQ, MethodName=RegistrationInfo_104b50e6558156a8bf2a3081b6e414f2 - Result=ExcelDna.Integration.ExcelEmpty ExcelDna.Integration Error: 1 : Integration.DnaLibraryAutoOpen Error : InvalidOperationException - Synchronization macro registration failed.

I browsed the ExcelDNA source code and can see the exception being thrown, but dont see much else that helps me resolve.

Anyone have any insights on additional steps to take? 

Thank very much! 

[Govert van Drimmelen]

It looks like the problem happen when Excel-DNA tries to get hold of the COM Application object.

This is tricky when an add-in is loaded as Excel starts up.

 

First, I should say that PIA assembly versions are not really an issue anymore, since .NET 4 and the embedding of the interop information at compile time.

Next, there are some Excel-DNA fixes related to the startup and getting the Application in the 5 years since version 0.33 was released. You might do some test with a newer version.

However, there are still some cases where the “Synchronization macro registration failed” error gets reported, so I’m not sure we’ve gotten to the bottom of it yet.

 

I would suggest the following test:

• Uninstall the add-in from Excel and restart Excel.
• Open a workbook or create a new one.
• Then do File -> Open and select the .xll to load.

 

I expect under this sequence that the problem will either be gone or at least look different. That might give us a clue.

 

From the stack trace, could it be that you are making some calls from some static constructor in a class like Backstop.UI.AddInImplementation.AddinScope?

 

-Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/eddb3187-3aea-49c4-8f22-2e96b3f63d36n%40googlegroups.com.

[Backstop Solutions]

Thanks very much, Govert.

Re: the static constructor, we do initialize a dependency injection module(Ninject) via that constructor which does grab references to the excel application object and tries to get the active workbook. To do that, we reference the ExcelDna.Integration.ExcelDnaUtil.Application and cast it to the Interop.Excel.Application object. 

I was not working on this project when that initialization code was written. Is it bad practice to reference the excel application via the static constructor? No other users have complained, but if it's bad practice, I'd like to avoid it.

I will also try updating to the latest version.

Thanks very much!

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/008701d6f346%24600d8f50%242028adf0%24%40icon.co.za.

[Backstop Solutions]

Hi, 

In case anyone bumps into my thread. It took a while to get back in sync with the customer, but the loading issue I described above was resolved by updating to the latest version of Excel DNA, in this case 1.1.1.

Thanks to Govert for his quick response and guidance. 

John Reagan