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.
Step 1: Host ApplicationFirst create the host application that will load the PlugIn.
Step 2: PlugIn SupportThe next thing you'll want to do is create either a class or function that will handle loading the plugins.
Step 3: Creating the PlugInNext, 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 PlugInThis 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.AnotherPlugInClassStep 5: Register the PlugInNext 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 PlugInNext 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 PlugInYou 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?
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.
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.
When I post the article, I will address this issue.
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.