Introduction

Back in the old days when I programmed with Visual C++ and DCOM, one of my favorite features was ‘Component Categories’. For those of you who are unfamiliar with DCOM, categories allowed the component developer to dynamically add behavior to an application by supporting a common interface and GUID pair. On application start-up, all registered components who supported a particular GUID could be identified and instantiated and subsequently communicated with via the common interface.

So far I have been unable to identify an equivalent in .NET Remoting, however after reading an article on .NET Reflection here on Code Project (the original source for which I can’t find but if you think you’re the author then contact me and I’ll give you your due credit), I think I’ve come up with something just as flexible.

Reflection

Reflection is nothing new to the Java development community, the basic idea is that metadata for all managed types can be accessed at runtime. This gives the developer the ability to interrogate the inheritance hierarchy of an object, invoke methods similar to IDispatch invoke, but most importantly to instantiate an object from its metadata definition. Couple this with the .NET ability to interrogate the exposed managed object types contained within a particular assembly, and you have the fundamental building blocks for a ‘Component Category’ alternative.

At this point, I’d like to point out that this Plugin API should not be seen as only applicable to Remote Object hosting. In fact, at the moment I use the API to add a vertical slice of functionality to my application space, from Menu options and Wizards to backend servers.

Plugin API

The basic Plugin API is quite simple; a PluginManager class is provided which takes a ‘Plugin Interface Type’ and can then return all the objects contained within the current working directory supporting that interface. The reason for the indirection between the Plugin interface and the Plugin object is that I wanted to be able to control the instantiation of the Plugin object, possibly through the use of a sub-class of the basic PluginManager class.

Generic Hosting Application

The creation of a generic hosting application to use this Remote Plugin Manager is then relatively straight forward. On startup, standard Remote objects can be configured using the normal XML configuration file followed by pluggable object configuration via the Remote Plugin Manager.

Deployment

All that needs to be done to deploy a new Remote object is to copy the DLL assembly into the working directory of the RemoteHostApp application. The hosting app presented here is very simple in that, to pick up the new Remote object it would have to be restarted. A very simple improvement to overcome this necessity would be to create a directory listener to detect when new files are added and existing one deleted.

Summary

In itself the Pluggable Remote API isn’t much of an improvement over the XML Deployment file, however when the pluggable concept is taken straight through to the GUI level, it becomes possible to add complete vertical slices of functionality to a core platform.

Downloads

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Sorry for the delay in getting back to you, it's been a while since I looked over this code. I'm not sure what you mean by extending the client. I use this code extensively in my company for deploying Remote Objects a runtime and yes a new servicechannell is registered.