Plugins again

Q

quwiltw

Contributor
Joined
Sep 18, 2001
Messages
486
Location
Washington, D.C.
I've taken a look at the examples for plugin/addins and I've got a prototype of a plugin framework working in VB.NET now. I'm struggling though with one problem.

I've created an interface IPlugin with the appropriate methods. The problem is that I have no way of knowing what the plugin developers call thier implementatio of IPlugin. Currently, I'm able to go through the entire plugin class collection and each classes respective interface collections in order to determine which one implements IPlugin and right now, with only small sample plugins, this is no big deal. But as plugins get larger, this gets messy. I would like to have a better strategy for this, like forcing the name of the implementing class to be something I dictate (which I doubt is possible) or something else. I've thought about maybe maintaining a little xml file that contains all the class implementations for each plugin then I'd only have to investigate the entire assembly once per plugin, but this too seems messy.

Any thoughts are appreciated.
 
like forcing the name of the implementing class to be something I dictate (which I doubt is possible)
Click to expand...
You can choose to ignore any class which doesn't follow some
naming convention you dictate, but it would be breaking the spirit
of OO/Interface programming. I know how I handle it with COM.
I make the user browse to a DLL that is supposed to contain a
class implementing my plugin interface. Then I iterate through the
classes and interfaces, looking for the GUID which is the interface
ID I assigned. I don't know what the equivalent is in .Net, but it
sounds like you are doing something similar.
 
Yep, I can find the implementing class, but it doesn't seem smart to do this each time as I understand reflection is rather expensive. I guess it comes down to

either
1) Take any assembly and investigate it for the implementing class, then store the class name in some plugins.config file the first time, then I've got a clean way to immediately launch a plugin.

or

2) Make a plugin developer also include a little config file that includes their implementing class name.

Having actually typed it out now, option 2 sounds pretty cheesy, I think I'll take option 1 unless you (or anyone else) can think of an option 3/4/5???
 
Anyone willing to look at what I've got so far? It's essentially a single solution with 4 projects
1 to define the Plugin Interfaces
1 to implement a IPluginHost
and 2 that implement IPlugin.

I'm sure the code itself can be cleaned up, I'm more concerned about the sanity of the design. Zipped up, it's ~97k. Let me know if you're willing to review it.

EDIT: By the way, I haven't included the config file yet. Currently it inspects the assemblies each and every time.
 
Back
Top