More than one ExcelDNA addin loaded

Sep 30, 2014 at 8:25 AM
Hi there,

Are there any known issues/recommendations when having more than one ExcelDNA addins loaded in Excel?
One thing I've noticed is when opening Excel with a blank workbook: in both addins we initialize a static property with ExcelDnaUtil.Application in AutoOpen method. When the second addin loads, it fires the WorkbookBeforeClose on the first addin when using the ExcelDNnaUtil.Application property.

Sep 30, 2014 at 10:39 AM
Hi Alex,

The add-ins live in separate AppDomains, so there should be limited interference at the .NET level.

If multiple add-ins register the same function or macro name, the last one wins. You can't load more that one add-in with the same file name (even in different directories).
The C API event handlers like ON.TIME can only be set to one macro at a time, so different add-ins could interfere there.

The Workbook close event you mention probably depends a bit on the sequence in which things are loaded. If Excel has not initialized the COM object model when the add-in loads, the only way I know of to force that is to create a hidden workbook (which is then closed again). This has some side effect, like making the first new book you create to be called "Book2". I'm not sure why we'd have the sequence you report though, with the second add-in seeing the close event, presumably coming from the first add-ins attempt to get the Application COM object.
Getting hold of the Application object reliably is one of the trickier parts of Excel-DNA.

Sep 30, 2014 at 3:15 PM
Thanks Govert.

The thing with the WorkbookBeforeClose handler is that we check if the workbook was saved, if not we ask the user if he wants to save.
When the 2 addins loads, and the second catch the Close event because the other one gets the application COM object, the current workbook Saved property is false. So basically we ask the user if he wants to save the Workbook "book2".
I'm not sure why the Saved property would be false here (the workbook is blank and nothing was changed), the only workaround I found is also check if the current workbook is not empty, but not ideal. Not sure if there is a better mechanism to avoid this.

Sep 30, 2014 at 10:10 PM
Hi Alex,

What if you delayed the work you want to do with the COM object model a few seconds?
You could set a timer in your AutoOpen, then in the timer event you call ExcelAsyncUtil.QueueAsMacro to schedule the startup code, where you then talk to the COM object model and hook up the events.

This might keep you out of the way of other add-ins a bit, so by the time you hook up your event the Application object will be created and the startup troubles will have passed.

Oct 2, 2014 at 8:24 AM
Thanks! I finally delayed the registration to WorkbookBeforeClose on one of the addin and this works great.