im playing with the plugins tutorial on this site which is great. i have one question. is there any way that i can have an identifier in a class library, and read that ( a string name or something) that i can use before the class is actually instantiated? its so i can get the names of all the various plugins, and put them in a combo box and the user can select which one they want to instantiate without instantiating all of them.
The way i've done this in the past is with a 2 tiered plug-in system (I think theres posts about it somewhere on the forums. Basically for each plugin you want you will have two classes the main class and a descriptor class, which will contain information such as name, possibly an icon, and a method for creating an instance of the main class. Then you load the descriptor classes with your plugin controller, allowing you to display them in a list. Then you can use the create method of each class to create an instance of the main plugin object.
This is true the entire assembly would still be loaded, as (as far as I know) its impossible to search for classes in an assembly without loading it. However it does mean the resource intensive objects do not need to be created untill they are required.
On recommendation I have then: the reflection namespace and classes have functions that allow loading assemblies for reflection only. This could probably save on resources if you set your plug-in system up so that any describing data you need can be obtained through reflection (custom attributes will probably work).
On recommendation I have then: the reflection namespace and classes have functions that allow loading assemblies for reflection only. This could probably save on resources if you set your plug-in system up so that any describing data you need can be obtained through reflection (custom attributes will probably work).
if i use attributes and look at them using reflection, is it possible to specify an attribute in the interface for the plugin, so all classes that implement the plugin have to contain that attribute, maby name or something?
does the fact that you have to have a descriptor class not go against the plugin idea that as long as you have an interface, the plugin will work with your specified app. with a descriptor class , you also need to create the descriptor class, which makes your plugins not as easily implementable by anyone . ( hope you get my point, kinda hard to put it into words
The descriptor class would add more complexity to the plug-in system. Essentially, however, the descriptor class would be part of the interface (by which I don't mean a .Net interface type, but rather your program's plug-in interface). It doesn't really go against the spirit of the plug-in. It just makes it less painless (a little more like pre-.Net days).
The descriptor, though, could be responsible for instantiating the plug-in object. I think that would make things a little simpler. For example, say your plug-in interface is IPlugIn with a descriptor interface IPlugInDescriptor. When you load an assembly you can search the types for IDescriptors and forget about looking for IPlugIns. When the user picks a plug-in based on data from an IPlugInDescriptor, you could call a function, like CreatePlugIng() for example, that would instantiate the plug-in class.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.