Accessing public shared members between add-ins

Add-in Express™ Support Service
That's what is more important than anything else

Accessing public shared members between add-ins
Accessing public members of your COM add-in from another add-in or app 
Jordan Blaydes




Posts: 37
Joined: 2009-02-08
I have read several threads on this topic in the forum but still do not understand how to implement a fix.

The on-line help suggests:


HostApp.COMAddins.Item({the ProgID of your add-in}).Object.MyPublicPropertyOrMethod(MyParameter)

Another thread suggested to:

Application.COMAddins.Item("YourAddin.ProgID").Object.YourPublicMethodOrProperty

This is pseudo-code? I cannot reference Application or HostApp.

Another thread suggested to:

Excel.Application a = (Excel.Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application");
object oIndex = "SwQuotes.Addin";
object obj = (a.COMAddIns as Microsoft.Office.Core.COMAddIns).Item(ref oIndex).Object;
object res = obj.GetType().InvokeMember("GetValue", System.Reflection.BindingFlags.InvokeMethod, null, obj, args);
return (decimal)res;

This is an example in C# but I am not able to translate this to VB without errors. This is my attempt in VB:

Dim a As Excel.Application = DirectCast(System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application"), Excel.Application)
Dim oIndex As Object = "ExcelAddInScopeADX.ExcelAddinModule"
Dim obj As Object = TryCast(a.COMAddIns, Microsoft.Office.Core.COMAddIns).Item(oIndex).[Object]
Dim objLicense As Object = obj.[GetType]().InvokeMember("ValidLicense", System.Reflection.BindingFlags.InvokeMethod, Nothing, obj, Nothing)

In that same thread, another suggestion:

Try calling a public method defined in your UDF in the AddinInitialize of your add-in module; see ExcelApp.Evaluate. This loads the UDF to the AppDomain of the COM add-in.

This does not work for me either. I declard a Public Sub and a Public Function in my ExcelAddInModule that is called in the AddinIntialize of the AddInModule, but once I try to access a UDF (Public Function) of the ExcelAddInModule (either through opening a workbook with a saved UDF or through a new workbook, the ExcelAddInModule is reloaded and a new instance of the Public Shared Member is created.

I have created a project to demonstrate the issue using ADX, and another Add-in that does not use ADX (Typical Shared Add-in). This shared add-in has no issues with a combined AppDomain. I can access the Public Shared members in between the COM Add-in and the Automation Add-in with no issues and only one instance of the Public Shared Member, so this seems like an issue related to add-in express and not with AppDomains in Excel.

I am using Add-in express 2008 with Visual Studio 2008
Microsoft Visual Studio 2008
Version 9.0.30729.1 SP
Microsoft .NET Framework
Version 3.5 SP1

Installed Edition: Professional
Add-in Express?Â?Ô?? 2008 for .NET v4.4.1913
Add-in Express?Â?Ô?? 2008 for .NET. For more information about Add-in Express?Â?Ô??, see the following website: http://www.add-in-express.com. Add-in Express?Â?Ô?? 2008 for .NET, Copyright © Add-in Express. All rights reserved.

Is there an e-mail address that I can send my project samples to you?
Posted 02 Jul, 2009 03:41:01 Top
Jordan Blaydes




Posts: 37
Joined: 2009-02-08
Hi, I was thinking about this issue some more and it may be that my Shared add-in example (COM add-in and Automation Add-in not using ADX) is working because they both have an entry point of mssoree.dll in Excel during debug mode. This would technically be the same AppDomain because I do not have a COM Shim yet. If I add this COM Shim, it may be that this issue will re-appear in my Shared add-in project. How is this handled in debug mode in ADX when using the adlauncher.dll as in entry point, are the add-ins kept in separate AppDomains?

Is there any chance of using the method described in this article as a workaround?
http://blogs.msdn.com/jackg/archive/2006/03/10/549046.aspx

"The host may also load multiple Add-in's into the same App Domain (clumping) where they have like semantics, such as; shared security context, life times, shared resources, etc..

Since you are crossing an AppDomain boundary (just as you would when crossing a process boundary) your objects need to be MarshalByRef (MBRO) and instantiated via System.Runtime.Remoting."

This last sentence refers to AppDomain boundaries being crossed by the host application (in our case our host would be the ADXLauncher?).

I really like ADX for it's ease of use, but need to unserstand it's limitations with sharing data between add-ins. Is this really possible?
Posted 02 Jul, 2009 12:52:42 Top
Jordan Blaydes




Posts: 37
Joined: 2009-02-08
I just saw this note on your website, I will look at the ExcelApp.Evaluate and see if it makes a difference in my ADX project.

Developing multiple Office extensions in the same project
If you develop several Office extensions in one assembly, you should understand that Office loads your assembly several times: say, if you have a COM add-in, an XLL add-in and an RTD server in the same assembly, the assembly will be loaded three times. Add-in Express loads all such extensions into the same AppDomain. The only exception is the Excel Automation Add-in, which is loaded to the default AppDomain. You can load your Excel Automation add-in into the same AppDomain as your COM add-in by calling any of its functions via ExcelApp.Evaluate. Note that COM add-ins, Excel Automation add-ins, and RTD servers can be installed either for the current user only or for all users on the PC. Smart Tags can be installed for all users only. XLL add-ins can be installed for the current user only.
Posted 02 Jul, 2009 13:16:08 Top
Jordan Blaydes




Posts: 37
Joined: 2009-02-08
This worked for me.

The suggestion in the other thread "Try calling a public method defined in your UDF in the AddinInitialize of your add-in module; see ExcelApp.Evaluate." was the right fix, but I didn't understand it until I read the portion on the website (shown in my last reply).

I hope this helps someone else down the road.

Posted 02 Jul, 2009 14:19:13 Top
Andrei Smolin


Add-in Express team


Posts: 18825
Joined: 2006-05-11
Hello Jordan,

HostApp.COMAddins.Item({the ProgID of your add-in}).Object.MyPublicPropertyOrMethod(MyParameter)

Another thread suggested to:

Application.COMAddins.Item("YourAddin.ProgID").Object.YourPublicMethodOrProperty


In VB.NET (if you have Options Strict Off), you can use either of the above but you need to replace HostApp with a correct reference to the Application object of the host application of your add-in.

Thank you for posting about your researches. I'm pretty sure this will help forum readers in the future.


Andrei Smolin
Add-in Express Team Leader
Posted 04 Jul, 2009 11:50:27 Top