I have had this question a number of times and surprised myself when I did not see it in my blog. So here goes.
There are times when (like my Master Add-in Entry), you need to expose a set of methods or properties in your add-in so that other add-ins or applications are able to access them. Here is how it is done:
1) You create an interface and a class that uses that interface, like this:
[ComVisibleAttribute(true)] public interface IExposedMethods { void LoadDocument(string path); } [ComVisibleAttribute(true)] [ClassInterface(ClassInterfaceType.None)] public class ExposedClass : IExposedMethods { public void LoadDocument(string path) { Globals.ThisAddIn.Application.Workbooks.Open(path); } }
2) Next, you need to add the following code to your ThisAddin.cs:
private ExposedClass _exposedInstance; protected override object RequestComAddInAutomationService() { if (_exposedInstance == null) _exposedInstance = new ExposedClass(); return _exposedInstance; }
3) And finally, to call it and access this from another application instance, you do this:
Excel.Application xlApp = new Excel.Application(); xlApp.Visible = true; object addinName = "MyAddinName"; Office.COMAddIn addIn = xlApp.COMAddIns.Item(ref addinName); addIn.Object.LoadDocument(@"c:\path\test.xlsm");
It is actually quite easy to implement. And the beauty here is that the ExposedClass you created can have all sorts of methods and properties that are exposed. And because the _exposedInstance is global to ThisAddIn (via Globals.ThisAddin._exposedInstance), you can access it anywhere. So it is a perfect way for one add-in to contact another or for a parent Windows Form application to reach into the Add-in and set properties and call methods and have it open documents and such for you.
While it resolves the issues of OLE initialization and allows you to edit your Excel embedding in Word (as one example), it does not prevent one other scenario that I like to call “Orphaned Excel.” In this scenario, you edit your embedded Excel instance in another Window (usually via a right-click / Ole Object / Open). If you leave Excel open, return to Word and close the document, Excel should close. But in the VSTO COM/OLE scenario it may not – it will remain open with the embedded workbook still editable. However, it is orphaned an no longer associated with its container. Any edits will be lost.
Your add-in is loading in the same AppDomain as everybody else. If there is another VSTO 3.5/4.0 Add-in loaded in Excel and that add-in is not doing any of the above – well, your still going to have problems. 
You can play by all the rules, but you cannot prevent other kids from throwing sand. This is why I see some customers going to the extreme to manage out (disable) all other COM add-ins when they load their solution. But this does not work for HKEY_LOCAL_MACHINE Loaded add-ins. 