How to create a plugin system

I want to create an application that uses plugins, i want loand and unload plugins, in vb6 i was using activeX dll's, but here is not the same, it's a good thing, but i dont know how to implement this, maybe someone could help me ...
[235 byte] By [GuesWho] at [2008-2-4]
# 1
In general, the idea is to create an interface and interact with created instances of an interface rather than concrete classes. Additionally, you can inherit from a base class that implements some base functionality. So for instance, lets say you wanted to create allow folks to plug in their own "notification" systems, you could do so by creating an interface called INotifier and perhaps provide some base functionality in a NotifierBase class.

The following link is in C# and was written for the 1.x framework but should provide at least some good background for you to follow.
http://weblogs.asp.net/rosherove/articles/7610.aspx

Check out my blog in the next week, I'll post an article on this to help clarify the issue.

TobinTitus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 2
the problem is .. that i need some vb express code .. like an ideea i got something, and i thank you...
GuesWho at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 3
Not a problem. I can help you out still. The code should function no matter what IDE you are using. Unless of course you were looking to write "plug-ins" for VB.NET express edition. In that case, we are talking a whole different example.
TobinTitus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 4
You may also want to look for open source frameworks to do this sort of thing, one of the best I have found is the Razor framework which is described in this article on codeproject.com. There is a workspace on gotdotnet and a supporting website.
SimonGeering at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 5
The link above still appeared to use DLLs for their PlugIn system. I don't know exactly what you want, but this is how I create plugins for my applications:

Step 1: Host Application

First create the host application that will load the PlugIn.

Step 2: PlugIn Support

The next thing you'll want to do is create either a class or function that will handle loading the plugins.

Step 3: Creating the PlugIn

Next, create a new library. Name the class whatever you'd like, or have a consant class name for each of the PlugIns. That'll determine the method you use to load the PlugIn.

Step 4: Compile the PlugIn

This is where you have two ways to do it. If you compile the PlugIns in the application folder, you can search the PlugIns folder for the DLLs and then have it load them, assuming there's a consistant class name between them.

If there isn't, then provide some type of file with the PlugIn name and the class name. For example:

MyPlugIn.PlugInClass
MyPlugIn2.AnotherPlugInClass

Step 5: Register the PlugIn

Next you need to make the PlugIn recognizable by windows using the regasm.exe tool provided with the .net framework. regsrv32.exe will not work with .net libraries.

Step 6: Load the PlugIn

Next thing to do is load the PlugIn using the CreateObject function in Visual Basic. It will be loaded using the name of the DLL, then the class name. You can load seperate classes from the same DLL:


Dim MyDLL As Object
MyDLL = CreateObject("DLLName.ClassName")

Step 7: Use the PlugIn

You can now use the PlugIn like any other object. For example: MsgBox(MyDLL.Author).
So I guess I have a question of my own - is there any way to load it without the use of regasm.exe?

Clodaus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 6

Yes, I'm working on an example and its taking me a while because I'm doing it in C# and VB.NET and trying to make it usable for about anyone.

The problem with the method you describe is its more akin to classic VB 6 programming. The best way to handle this is with interfaces and a good understanding of OO.

Instead of calling an object directly, the key will be to load an type based on a configuration file pointing to the type name and/or file path of the assembly. The type you point to should implement an interface that your application also has access to. There are several ways to handle this once you've got it loaded. You can either hook up events / delegates against your application, or you can use the interface instead of directly calling the instance.

Much of the .NET 2.0 Framework uses this concept in a slightly different manner. They refer to it as a provider model. It is essentially the same thing (with variations). You expect a type to implement a certain provider's interface , you load the provider based on the application configuration, then call it through the interface.

TobinTitus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 7

Sorry for the delay. I've been extremely wrapped up lately. I didn't want to forget you though so I made a quick example of a plugin architecture in VB.NET. It's not perfect or complete yet. I intend to clean up the code from a patterns / practices standpoint, then convert it to C# and create an article. But since I'm sure you don't want to wait on me for this all, and to get you started right away, here's a link to the current source code for the demo. Let me know if you have any questions. I'll be up in Redmond all next week so I won't likely be able to respond until Saturday, but I'll try to check the forums a couple times just in case.

*EDIT* One other thing. In the demo, I made a reference from the WindowsPluginHost to the WindowsPlugin project. This was for the sake of easier testing. Plugin assemblies do not need to be referenced by their plugin host projects. They simply need to be placed in the same directory as the exe so normal probing operations will find the assembly when trying to load the type.

TobinTitus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 8
I should also mention that the current example loads all assemblies into the current appdomain which isn't always desirable. That is because once they are loaded into an appdomain, they cannot be unloaded without unloading the entire appdomain. Because of this, many times it is desirable to load assemblies into another appdomain so once the plugin's usefullness has expired, you may drop the plugin appdomain and release the assembly.

When I post the article, I will address this issue.

TobinTitus at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 9
Basically, you define an interface that the plug-ins exposes. You may also wish to check out reflection, which is the technology to allow you to example assemblies and see what methods, properties and events that assembly is exposing.
RichardR at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...
# 10
Some examples in Code Project, using different implementations:
http://www.codeproject.com/csharp/PluginsInCSharp.asp
http://www.codeproject.com/csharp/pluginmanager.asp
http://www.codeproject.com/csharp/C__Plugin_Architecture.asp

I'm not very sure of modules running independently though, maybe you're thinking of running in separate application domains?
http://msdn2.microsoft.com/en-us/library/ms173138
Hope this help.

SincerePrayer at 2007-9-8 > top of Msdn Tech,Visual Basic,Visual Basic Language...