Windows service runs like a scheduler service, not able to resolve dependent assembly references at run time.

Question

I have a windows service which runs like a scheduler, it extends an interface which can be implemented by other classes to become plugin to this service. All plug-ins (eg Plugin1, Plugin2...) would be dropped in sub folder of PlugIn such as PlugIn\Plugin1, PlugIn\Plugin2 respectively. At runtime each of the subfolders (Plugin1, Plugin2) would be searched for any assembly implementing the interface and a timer would be scheduled with the corresponding dlls method.

Now in case Plugin1 & Plugin2 share a common.dll (private assembly) the scheduler loads it only once (whichever occured first). If for some business reasons we update common.dll for Plugin1 and copy it in Plugin1 folder, keeping Plugin2 with previous version, which becomes a problem because now common.dll would be loaded non deterministicaly.

Is there a way I could tie the set of binaries (from the respective folder) with the timer at the time of scheduling or later?

Answer 1

It sounds to me like the thing to do here is to create an AppDomain per plugin / implementation, and use each plugins folder as the bin path. That way, each plugin can run with its own set of completely isolated assemblies.

The other (even more isolated) approach is to create a Process per call; that can be very effective and is simpler than handling AppDomains.

There is a vast range of info about working with AppDomains linked from here (see the table).

Answer 2

A simple solution would be to use ILMerge to merge all assemblies of a plugin into a single assembly. That should take care of it.