The application I develop uses add-ins with the .NET add-in functionality provided by System.AddIn. My host application as well as the add-ins share some resources like WPF embedded fonts and XAML icons. I'd like to avoid including them in both the host and the add-ins. Is there any way to achieve this without too much complexity?
My application already consists of 7 parts: The host, host-side view, host-side adapter, contract, add-in-side adapter, add-in-side view and finally the add-in. The problem I see is that, while the host loads the add-in assemblies, it's impossible for the add-in to access resources located in the host assembly.
The add-in provides a service which the host consumes. I want my host to provide resources which the add-in consumes.
A possible solution would be to introduce another assembly containing all the resources, which is accessed by both the host and the add-ins. What are the positive / negative aspects of this solution? Like, can an add-in rely on the existence of this assembly when it's not a contract?
You can expose the host to the add-ins by adding a contract for the host as well. Then the add-ins will be able to ask for resources that the host can provide. Look at the Basic Automation Object Model sample from the
System.AddInteam. There you will find theIHostObjectContractwhich is the contract for the host and is provided to each add-in during initialization (IAutomationAddInContract.Initialize).The other approach with the shared assembly is also possible. Remember though that
System.AddInis not just a library. If you don't follow their guidelines you might lose some of the features. Usually the first thing to lose is versioning. By adding a shared assembly you will risk losing versioning. If you can live with it or if you are certain that the shared assembly's public types will never change then go for it.