Best way to build a hot pluggable WCF service library

Question

I have been working on a WCF service library where hopefully all the business logic will end up living. The problem that I am running into is that sometimes I have to make quick fixes to a service and in order to apply those fixes I have to stop the Windows Service, replace the service dll and then restart the Windows service. This is going to start to cause additional headaches as we start migrating more and more of our logic to this layer and have to shutdown the entire service in order to make any changes.

What I would like to do is create an empty shell of a Windows service and dynamically load and unload the services. What is the best way to load and unload .Net DLLs on demand? Or is it better to rely on IIS for this kind of service?

Answer 1

You can probably use reflection to dynamically load specific logic you need, but the performance hit on your services is going to be tremendous doing what you want you described.

If you haven't used reflection before, here is a sample I grabbed from a project I have. It shows how to load an assembly and call a method with some parameters.

Assembly a = GetAssembly();
Type t = ExportModule.GetExportType(a);
if (t == null) throw new Exception("No proper type found.");

object iExportModule = Activator.CreateInstance(t);
object[] arguments = new object[] { _export.ConnectionString, GetFileName() };

t.InvokeMember("ExecuteExport", BindingFlags.Default | BindingFlags.InvokeMethod,
     null, iExportModule, arguments);

Obviously I don't know your environment, but in general I would say that its much better to shut down the service for a few minutes to update the software than to change your entire paradigm to be dynamic.

If you really have constant hot-fixes that require the service to come down I don't think you should have one central service. You'd be taking it down all the time. Better to have separate services dealing with different logical functions so your entire application isn't brought down (single point of failure).

Answer 2

Once an assembly has been loaded into an AppDomain, it will remain in memory until that AppDomain is unloaded and destroyed. Therefore in order to simulate a "hot pluggable" environment, you have to setup and tear down AppDomains (from the main process' AppDomain) that will host the actual business assemblies and run the application logic.

Needless to say, you should expect performance degradation if you constantly create/destroy AppDomains per WCF service call. It is meant to create an operating boundary isolated from your main AppDomain to do meaningful work that lasts for a good duration. The advantage with AppDomains is you can conserve memory usage if you have quite a lot of business logic assemblies that you would like to unload over time.

The prime example of this type of dynamic setup and tear-down is ASP.NET. The ASP.NET runtime creates an AppDomain for each web application. If something changes in the web site, like web.config, the AppDomain is unloaded and a new AppDomain setup for the new version of the web application - application recycle.

Answer 3

If you are using WCF, one name you need to be familiar with is Juval Lowy. He is the founder of IDesign and one of the most recognized experts regarding WCF. His book Programming WCF Services is highly recommended.

The IDesign website offers a whole series of free-to-use downloads related to WCF. All you have to do is provide your email address and abide by IDesign's standard licensing agreement.

Of particular interest to you may be the App Domain Host, the In-Proc Factory, and the In-Proc Hosting downloads found here.

Answer 4

Try using MEF for managing dependencies along with MAF (System.AddIn) for loading/unloading addins.