Sharing an Instance of an AddIn?

Mar 14, 2008 at 6:23 AM
Here is what I am trying to achieve...

I have three entities:
1 - Main Application (Host)
2 - Shared Addin (Addin)
3 - Addin which also loads the shared addin (Addin and Host)

I want my main application (1) to load both addins (2) and (3).
I also want addin (3) to load addin (2).
I also want (1) and (3) to get the same instance of the shared addin (2).
It sounds easy enough but I am really struggling to figure out how.

If both 1 and 3 call their own versions of FindAddIns() and Activate() then I get two instances of the shared AddIn (2), even if everything is being loaded in the same AppDomain.

I found this old link:
It says:
5. Passing and Re-Adapting Add-In’s (ContractAdapter)
One of the many benefits of the Adapter model is the ability to Re-Adapt. Sharing Add-In’s without the demand to Discover and instantiate a new instance is a powerful capability.
We provide facilities to pass the Add-in around and let each consumer of it choose its own view and let the system find the appropriate adapter between the activated add-in and the requested view.

This sounds like exactly what I am after, are there any examples around that use the ContractAdapter class in this way?
Am I way off track here, is what I am trying even possible (or desirable)?
Mar 18, 2008 at 9:14 PM
What you're describing isn't terribly common but it is supported and is not a rare scenarios. It should also be pretty straight-forward to implement once you think about it in the right way.

ContractAdapter isone way to do this but in your case are probably overkill. It is designed for cases where the main application doesn't know anything about the types of the different add-ins (that is: doesn't have a host view for them) but still wants to facilitate passing one add-in to another.

Instead, you can simply make one the methods the host exposes to entity 3, be one where entity 3 can request entity 2 from the host. The host will do the activation and just pass the shared add-in (entity 2) to the other add-in (entity 3) when it is requested.

You won't have to do anything fancy in your pipeline either. Simply have the return value of a method (through which #3 will ask #1 for #2) be the type of contract you defined for entity 2. The pipeline builder will do the right thing and build the right code to enable this.

Does this make sense?
Apr 1, 2008 at 1:24 AM
Edited Apr 1, 2008 at 1:26 AM
Hack, you can find some sample code showing this at - JackG
Apr 30, 2008 at 7:20 AM
Thanks for the info guys, I’ve been on holidays so I apologise for the tardiness of this reply.
If I understand what you are both saying then it is very similar to an approach I tried (and failed at) while struggling with this problem. Your replies have clarified how I can get the host to expose addins activated in the host to other addins. In particular in your sample code Jack, you have 2 contracts...

public interface IAuthProviderContract : IContract
void Initialize(IHostObjectContract HostObjectContract);

public interface IHostObjectContract : IContract
IListContract<IAuthProviderContract> GetProviders(...);

This works for a specific contract, but I don’t really want my host to know what types of contracts it is loading and serving to the addins. Thus I would need a little more flexibility to make it generic i.e.
IListContract<T> GetProviders<T>(...) where T : IContract

Then my addins could call back to the host for an implementation of any contract, recieve the list of host views that implement the contract, and then decide which of the host views to use (if there are more than one). All the host views would be discovered and activated by the host and instances passed to my addins would be shared (woohoo).

I haven’t tried this out yet, but is there any obvious reason this wouldn’t work?
Also, why isn’t the IHostObjectContract (above) decorated with the AddInContract attribute?
Jul 9, 2008 at 4:02 PM
Hi Hack,

I think what you're looking to do is the subject of my blog post here.