This project has moved. For the latest updates, please go here.

StackOverflow Exception in CurrentDomain_AssemblyResolve in Sample.ExcelAddin

Dec 2, 2014 at 5:10 PM
I downloaded the 1.7.2 code and opened the Google Translation solution. Set Sample.ExcelAddin as the startup and set Excel 2013 (Office15) exe to start when the project loaded.

When it loads it eventually hits a Stackoverflow exception when trying to resolve the assembly.

Here's a screenshot http://imgur.com/owJHyXa

I'm not really sure what else to do here. It looks like this sample won't work in Excel 2013.
Coordinator
Dec 2, 2014 at 5:41 PM
holy shit ...

which .net framework ?
Dec 2, 2014 at 5:43 PM
.NET 4.5.1, VS 2012
Coordinator
Dec 2, 2014 at 6:12 PM
I cant reproduce the problem at the moment.
What i see in your screenshot is the problem occours in ClassicUI example addin.dll
I create a scenario with 3 loaded example addins(IExtensibility) and Google Translation
and no problems so far.

please add a ctor to COMAddinClassicExampleCS45 and put the following code line on it:

// log NO sys operations to console
NetOffice.Core.Default.Console.Mode = DebugConsoleMode.Console;

or:

// log NO sys operations to logfile
NetOffice.Core.Default.Console.FileName = "C:\LogDirectory\NO.log";
NetOffice.Core.Default.Console.Mode = DebugConsoleMode.File;

and send me the log content.
This could be help to identifier the assembly resolve arguments and find the problem.

Sebastian
Dec 3, 2014 at 12:10 AM
It looks like this was happening because I had two addins loading that were NetOffice based. Removing one of them made the exception go away.
Coordinator
Dec 3, 2014 at 1:31 AM
i agree but why its not occurs on my test systems? (i have much more NO based addins running)
i create a filter in assembly resolve event now to avoid resolve same assembly more than once.
if this error comes again you can do me a pleasure with log content to pin point the problem!

*Sebastian
Dec 3, 2014 at 1:33 AM
OK will do.
Jan 23, 2015 at 12:50 PM
Edited Jan 23, 2015 at 1:22 PM
Hi Sebastian,

We've seen this with an out-of-process application that accesses Excel through COM. The log (enabled with your code above) was of the form:

NetOffice Core.Initialize() NO Version:1.7.2.0 DeepLevel:True
Recieve IFactoryInfo:ExcelApi, Version=1.7.2.0, Culture=neutral, PublicKeyToken=9084b9221296229e:ExcelApi, Version=1.7.2.0, Culture=neutral, PublicKeyToken=9084b9221296229e
Try to resolve assembly OfficeApi, Version=1.6.0.0, Culture=neutral, PublicKeyToken=a39beb0835c43c8e
Try to resolve assembly OfficeApi, Version=1.6.0.0, Culture=neutral, PublicKeyToken=a39beb0835c43c8e
Try to resolve assembly OfficeApi, Version=1.6.0.0, Culture=neutral, PublicKeyToken=a39beb0835c43c8e
[repeats]

Clearly here we had two assemblies referencing different versions (1.7.2.0 and 1.6.0.0). The stack trace looked something like this:

Stack Trace

Easily fixed by updating the older reference, thought you (and possibly others) might be interested to see it.