I have a windows service. The idea is to execute as many different tasks as possible. Lets say we have this IServicePart interface with Start() and Stop() methods. When the service starts it will search all assemblies in some directory and find all classes which implements IServicePart. Done, no problem.
The problem:
Assembly1.dll is a good candidate for IServicePart. But it needs a configuration. For example Assembly1.dll.config. Now I can copy/paste/rename the dll to task2.dll and task2.dll.config and create a second task for the service. Each of those plugins comes with 10-20 dll dependencies
1) The most obvious problem is how to load the configuration, because the service host’s appDomain is different than assembly1 and task2.
2) I expect issues when I try to load the two IServiceParts when they depend on the same 3rd party assemblies
Solution 1 is to make a custom configuration and not use the app.config.
Solution 2 is to run each plugin in its own appDomain.
What are your suggestions.
Hope I explained this correctly
===================
reference: similar question here: Plugin to use its own app.config
The way I’ve done this, involves having each plugin in its own app domain. However, the codebase property of those appdomains continue to point to the root directory where my service exe is located. This achieves two things:
The many tertiary dependencies that the plugins have now don’t need to be duplicated. For example, I can put my logger assembly in the root folder (with the service exe) and all the plugins can see it. This is great, because I neither wish to put my logger assembly into each plugin subdirectory, nor do I wish to use the GAC.
All plugins now share the same app config (the same one used by the service exe). This is a good or bad thing, depending on your needs. But don’t forget the configSource attribute, which can allow you to put specific config sections into seperate config files within your plugin subdirectories.
Incidentally, I’ve been using MAF for my plugins.