Ideas for an extensible (addins / plugins) WCF service?

Question

I am looking for suggestions on how I can build an extensible WCF server (with dynamically loaded services), preferably using System.Addins or MEF.

The server must host any WCF service (contained in DLL assemblies loaded at runtime) that implements the minimum plug-in API (StartService / StopService / GetStatus? / Etc).

This post is a good start. Some goals and points for discussion:

• Use / not use isolated AppDomain for each service?
• How to configure each service (endpoints, transport protocols)? XML-config file or better alternative?
• Delayed / lazy loading of assemblies (when a service request arrives)? Possible? Is it helpful? How?
• Reloading the assembly when changing the file on disk (useful for the development environment);
• Restarting the service when changing the configuration on the disk;

and, of course, other ideas are always welcome;)

Answer 1

• Yes, use an isolated AppDomain for each service. You need AppDomain isolation so that you do not remove other services that run if one of them is omitted.

• Offer all WCF methods at the moment, either through programming or through configuration. Programmatic access is difficult because the ServiceHost instance is not serializable, so getting information across the domain border of the application will be painful.

• I would say that this is possible. However, this is mainly copying the Windows Activation Service , so you can start looking for your functions there.

• This is useful for development, but to be honest, I do not think this is an important function. This complicates your code for amplification, which is not too measurable (IMO). I would rather write a script that will stop the service, copy the file and restart it, instead of abusing the code base and will always monitor the build.

• Now you are talking about IIS. Essentially, IIS can host its service, and it will recycle it when the configuration file changes.

All that was said, it seems that WAS and IIS offer you most of what you want (very affordable, isolated application domains, configuration, etc. etc.), so you may ask why you wanted to do it yourself.