GetExcelAddIns CreateInstance problem (only on one machine)

[Alain Bryden]

I'm encountering an issue whereby a particular user's ribbon silently doesn't show up. Custom UDFs do show up, but if they try to use one, Excel crashes.

I loaded up Visual Studio on their machine, attached a debugger to Excel, and was able to observe some interesting Exceptions being thrown as Excel attempted to load the add-in on their machine.

When first opened:

Exception thrown at 0x7637B022 (KernelBase.dll) in EXCEL.EXE: 0xE0434352 (parameters: 0x80131604, 0x00000000, 0x00000000, 0x00000000, 0x749D0000).
ExcelDna.Integration Warning: 1 : GetExcelAddIns CreateInstance problem for type: AnalyzeRe.ExcelDNA.AnalyzeReRibbon - exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load type 'AnalyzeRe.Properties.SharedSettingsProvider' from assembly 'AnalyzeRe.Client, Version=1.28.6579.40706, Culture=neutral, PublicKeyToken=null'.
   at AnalyzeRe.ExcelDNA.AnalyzeReRibbon..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.RuntimeType.CreateInstanceDefaultCtor(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)

Exception thrown at 0x7637B022 (KernelBase.dll) in EXCEL.EXE: 0xE0434352 (parameters: 0x80131522, 0x00000000, 0x00000000, 0x00000000, 0x749D0000).
ExcelDna.Integration Warning: 1 : Type AnalyzeRe.ExcelDNA.Properties.Settings could not be processed. Error: System.TypeLoadException: Could not load type 'AnalyzeRe.Properties.SharedSettingsProvider' from assembly 'AnalyzeRe.Client, Version=1.35.6836.24274, Culture=neutral, PublicKeyToken=null'.
   at System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule pModule, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob, Int32* pcNamedArgs)
   at System.Reflection.CustomAttribute.CreateCaObject(RuntimeModule module, IRuntimeMethodInfo ctor, IntPtr& blob, IntPtr blobEnd, Int32& namedArgs)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeType type, RuntimeType caType, Boolean inherit)
   at System.RuntimeType.GetCustomAttributes(Boolean inherit)
   at ExcelDna.Integration.AssemblyLoader.ProcessAssemblies(List`1 assemblies, List`1 methods, List`1 addIns, List`1 rtdServerTypes, List`1 comClassTypes)

So already I'm perplexed. It looks as though two separate calls to my assembly (one by GetExcelAddIns and one by ProcessAssemblies) have failed ("AnalyzeRe.ExcelDNA" is me) - and even more strangely, the failures were to two different versions of my dependency:

- 'AnalyzeRe.Client, Version=1.28.6579.40706

- 'AnalyzeRe.Client, Version=1.35.6836.24274

This is especially confusing because I build that version of the add-in using version 1.38.6960.20921 of the dependency - so somehow, the add-in is trying to load older versions of the dependency on this particular client's machine.

For years now, I've been packing my dependencies into the add-in without issue, using the following .dna file entry:

  ...
  <Reference Path="AnalyzeRe.Client.dll" Pack="true" />
  <Reference Path="Newtonsoft.Json.dll" Pack="true" />
  <Reference Path="RestSharp.dll" Pack="true" />
  ...

Is it possible that whatever machine was used to build this add-in has somehow failed to pack the dependencies?

Is there any way to check the "AddIn.xll" file itself and verify whether the dependencies are indeed packed in there? If they are, any way to diagnose why those assemblies aren't being discovered when the user opens the add-in?

In case it's helpful - there is one other exception I was able to catch. After the above errors are thrown and silently caught - Excel keeps running (just without the Ribbon loaded).  But if the user then attempts to use one of the Excel formulas, the following Exception is raised:

System.TypeInitializationException: The type initializer for 'AnalyzeRe.ExcelDNA.ExcelAPI' threw an exception. ---> System.MissingFieldException: Field not found: 'AnalyzeRe.JsonConverters.AnalyzeReJsonConverter.Default'.
   at AnalyzeRe.ExcelDNA.ExcelAPI..cctor()
   --- End of inner exception stack trace ---
   at AnalyzeRe.ExcelDNA.ExcelAPI.IsEditingFunction()
   at AnalyzeRe.ExcelDNA.UDFs.TestConnection(Object Url, Object Username, Object Password, Object Path, Object Method)

After that, Excel crashes.

Any thoughts or potential next steps for investigation are much appreciated.

[Alain Bryden]

Sanity check: I went through the user's GAC (Global Assembly Cache) and none of my assemblies were in there.

[Govert van Drimmelen]

I'm guessing there's a weird version of your client library on the path somewhere. You can enable the .NET 'fusion logging' to track exactly how and which assemblies are loaded.

If not that, there's an Excel-DNA unpack project on GitHub that unpacks the xll.

-Govert

On Mon, 11 Mar 2019, 21:37 Alain Bryden, <al...@analyzere.com> wrote:

Sanity check: I went through the user's GAC (Global Assembly Cache) and none of my assemblies were in there.

--
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 post to this group, send email to exce...@googlegroups.com.
Visit this group at https://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.

[Alain Bryden]

Mystery (somewhat) solved:

The user's "Downloads" folder, which contained the add-in as well as the 10,000 other files they've downloaded in the past 5 years, also happened to contain a stray AnalyzeRe.Client.dll file they had previously downloaded for some independent development work.

Sure enough, the version of that dll was the old version the framework was now trying to use according to the stack trace (1.28.6579.40706). Deleting the file from the downloads directory immediately fixed the add-in.

I was somewhat familiar with the fact that the .NET framework would "magically" find overriding .config files for your applications if they were dropped int he same folder as the executable, but I didn't know this went as far as overriding the .dlls you packed in with something from the local directory. Now I know!

I suppose the next steps are to find the correct way to reference my dependencies (which all come as a NuGet packages) in a way that doesn't let the framework decide to just substitute out versions like that.

[Govert van Drimmelen]

The ExcelDnaPack mechanism which loads the assembly from the packed .xll is only invoked if the assembly fails to load through the normal .NET mechanism.

The .NET Framework makes it really hard for us to interfere with the loading if the required file (or one with the same name) is present in the directory.

So there’s no easy approach that would have worked in this case.

 

-Govert

--

[Bryden, Alain]

Do you think there could be a way to be strict about the assembly version we wish to load – such that the .NET framework is guaranteed to fail unless it happens to encounter exactly what’s packed into the add-in?

 

--

Alain Bryden

Analyze Re

 

From: Govert van Drimmelen <govert.va...@gmail.com> On Behalf Of Govert van Drimmelen
Sent: March 12, 2019 9:34 AM
To: exce...@googlegroups.com
Subject: RE: [ExcelDna] Re: GetExcelAddIns CreateInstance problem (only on one machine)

 

The ExcelDnaPack mechanism which loads the assembly from the packed .xll is only invoked if the assembly fails to load through the normal .NET mechanism.

The .NET Framework makes it really hard for us to interfere with the loading if the required file (or one with the same name) is present in the directory.

So there’s no easy approach that would have worked in this case.

 

-Govert

 

---

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.

[Govert van Drimmelen]

No way that I know of.

 

-Govert

 

 

From: exce...@googlegroups.com <exce...@googlegroups.com> On Behalf Of Bryden, Alain
Sent: 12 March 2019 14:38
To: exce...@googlegroups.com
Subject: RE: [ExcelDna] Re: GetExcelAddIns CreateInstance problem (only on one machine)

 

Do you think there could be a way to be strict about the assembly version we wish to load – such that the .NET framework is guaranteed to fail unless it happens to encounter exactly what’s packed into the add-in?

 

--

Alain Bryden

Analyze Re

 

From: Govert van Drimmelen <govert.va...@gmail.com> On Behalf Of Govert van Drimmelen
Sent: March 12, 2019 9:34 AM
To: exce...@googlegroups.com
Subject: RE: [ExcelDna] Re: GetExcelAddIns CreateInstance problem (only on one machine)

 

The ExcelDnaPack mechanism which loads the assembly from the packed .xll is only invoked if the assembly fails to load through the normal .NET mechanism.

The .NET Framework makes it really hard for us to interfere with the loading if the required file (or one with the same name) is present in the directory.

So there’s no easy approach that would have worked in this case.

 

-Govert

 

 

---

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.

--