Design structure for C# Excel COM Addin

Question

I am building a COM add-in for Excel 2007+ which will be an application in the sense that:

It has its own tab on the Ribbon with buttons that control its operation (such as "create new planning workbook"/"refresh workbook" etc.)
It will trap events from Excel (both Application and Workbook) and act upon them.
It should have a task pane which will be context-based, and will have data sent to it from my addin.

In order to support this I would like to structure the code in such a way that I can modify it relativley easily in the future (for example, adding a new button on the Ribbon) and not have spaghetti everywhere.

My initial thoughts were to create a singleton class which would be my "Addin Application" and initialise this with the Excel application itself, for example:

public class Connect : Extensibility.IDTExtensibility2 {
    private Excel.Application _excelApplication;
    private MyAddinApplication _myAddinApplication;

    public void OnConnection(Object application,...) {
        _excelApplication = (Excel.Application)application;
        _myAddinApplication = new MyAddinApplication(_excelApplication);
    }
}

This MyAddinApplication class would then trap Excel's events (such as opening a workbook, closing etc.) and then act on them accordingly. It would also trap any Ribbon events or callbacks and then trigger actions based on a Command pattern.

My question, is this a reasonable approach for an Excel COM addin? Would it be better to encapsulate the Excel application in a separate "event handler" class which is referenced by my "Addin Application" class? I've not really seen a complex COM addin from my research, only ones which have one or two buttons or do not trap any events.

I would consider looking at http://exceldna.codeplex.com/ - it has a lot of functionality and a pretty decent design. Also it is faster as the addin is based on Xll instead of COM. — weismat, Mar 12 '14 at 13:25
well, you're are making a VSTO add-in which is already well structured for you so I don't understand your question here. When you add a button to a ribbon with an event you will be redirected in the right place(code block) in your solution that stores all button events. When creating a CustomTaskPane you are most likely going to be adding a folder CustomTaskPane for anything CTP related...I seriously don't understand what you are trying to re-structure here.. Have you actually built one and got familiar with the current solution and code structure that VS suggests? What don't you like about it — , Mar 12 '14 at 13:45
@mehow I am not using VSTO at all, this is a plain COM addin. — i_saw_drones, Mar 12 '14 at 14:06
for the purpose you've described a VSTO is just perfectly. Why reinvent the wheel? You should really look at converting your *plain* com-add-in to a VSTO add-in which in the end serves the same purpose. See [this interesting read](http://stackoverflow.com/questions/1998824/automation-add-in-vs-com-add-in) — , Mar 12 '14 at 14:21

Mitja Bezenšek · Accepted Answer · 2014-03-12T16:08:42.227

Here is one (a bit more complex) Excel addin you can look at. The author describes how he organized his solution into different projects and I agree with most of his decisions. He separates the domain logic from the user interface / excel and also adds unit testing project and one project that bootstraps his whole addin:

http://www.clear-lines.com/blog/post/VSTO-solution-organization.aspx

Source code is available here: http://vstostocks.codeplex.com/

This is a VSTO solution but you can easily apply the same principles to a plain COM addin. It also quite similar to your project.

It is hard to give guidelines without knowing specifics of you problem. I think if you stick to main guidelines when it comes to OO design like SOLID, writing clean code, you should be just fine.

Design structure for C# Excel COM Addin

1 Answers1