Why doesn't ExcelDNA.Loader statically reference ExcelDNA.Integration

Sep 4, 2013 at 8:13 AM
Hi Govert,

I see that the methods in ExcelDNA.Loader make calls to methods in ExcelDNA.Integration via reflection instead of direct calls.

Is this for better control over how ExcelDNA.Integration is loaded? I would appreciate it if you could explain the reasons for this design.

Regards,
Koustubh
Coordinator
Sep 5, 2013 at 7:30 PM
Hi Koustubh,

I'm not sure it's really necessary, and I can't remember the whole evolution off-hand.
It might change in future.

ExcelDna.Loader is loaded from native code where it's pretty hard to deal with additional assembly resolution, which might be the case if ExcelDna.Loader were to automatically attempt to load ExcelDna.Integration. By making the hook-up explicit via reflection, I was hoping to have more control of when and how that assembly gets loaded. This is particularly required in the single-file packed case, where we have to case the assembly resolution failure and load the assembly from resources on the fly. I want this resolution and unpacking to be in managed code (so in ExcelDna.Loader) but then the runtime must not have tried (and failed) to load ExcelDna.Integration earlier.

I'm still not sure whether referenced assemblies are guaranteed not to be resolved until JIT-time, and whether a class or method is guaranteed not to get JITted until it is used for the first time.
Do you know what the .NET spec says about this?

Regards,
Govert
Sep 6, 2013 at 6:56 AM
Edited Sep 6, 2013 at 7:13 AM
Hi Govert,

Thanks for the response. I haven't looked at the .NET spec but this StackOverflow answer suggests that at least in practice, an assembly reference will only be resolved when code that references a type in that assembly is first JITed. My copy of CLR via C# says the same thing on page 87 (in the section How the Runtime Resolves Type References) including a flow chart for the resolution process.

Of course, NGEN might cause issues, but that doesn't apply in this case.

Having prototyped my project on Excel DNA, I am now building a C++ add-in using Keith's xll project and want the ribbon integration and access to the COM model that Excel DNA provides. So I am taking the parts of your code that are relevant for this. Since I am not building a generic platform, I think I can put everything in a single assembly avoiding this issue entirely.

Thank you for your efforts on Excel DNA.

As part of my work I have modified the ExcelDnaLoader.cpp and ExcelDna.cpp files to remove dependencies on MFC/ATL so that I can use Visual Studio Express. I have got it to work and if you wish, I can contribute the code once I clean up the modifications properly.

Regards,
Koustubh
Coordinator
Sep 6, 2013 at 8:37 AM
Hi Koustoubh,

Yes - I'd certainly like to consider a version that can build with Visual Studio Express without the ATL dependencies, so please send if you have something.

Regards,
Govert