Can an abstract class be used as the contract object between a 'Host' and a 'plugin'? The idea is that the plugin inherits the contract (we call it an adapter). We are also understanding that all participants in the framework must inherit MarshalByRefObject (MBRO). So, this is what we were thinking -
Host:
class Host : MarshalByRefObject
{
}
Contract:
public abstract class PluginAdapter : MarshalByRefObject
{
}
Plugin:
class myPlugin : PluginAdapter
{
}
All three exist in separate asm's. Our Host will create a new AppDomain for each plugin, and the PluginAdapter is created as follows:
{
ObjectHandle instHandle = Activator.CreateInstance(
newDomain, data.Assembly.FullName, data.EntryPoint.FullName);
PluginAdapter adapter = (PluginAdapter)instHandle.Unwrap();
}
EDIT: where data is the concrete type of myPlugin.
We were wondering if this implementation of the framework would work. We have seen articles using an interface (IPlugin) for the plugin derivation, and a concrete class as the contract. Those articles would also say that an abstract class can be used, but no examples of that implementation given. Is it required that the contract be a concrete class?
EDIT: In this example by Richard Blewett - C# Reflection - he uses a much simpler implementation:
Contract:
public interface IPlugIn
{
// do stuff
}
Plugin:
public class PlugIn : MarshalByRefObject, IPlugIn
{
}
Now, if using an abstract class as the contract, the Plugin cannot inherit both the contract and MBRO. What, then, becomes the best implementation for a scalable plugin framework. Should we go ahead and implement remoting even though, initially, we are developing for single-machine operation? This project is expected to become distributed across a network, possibly across the Internet as well. We simply have not implemented Tcp yet because we are trying to get the basics of a plugin framework fully understood and operational.
Does it make sense to implement Tcp remoting on a single machine using loopback?