Jonny,
Too bad you had to work today... got to pay the bills though
Plugins will certainly work in your case. Before jumping into that, let me offer another option for your situation.
Your reply in regards to "My Form (I belive you call this an interface)" makes me want to explain a little more about what an interface is.
Let me do that by providing an example of a program I am currently working on. I am building a communications driver for a piece of hardware that is capable of communicating either by TCP (sockets) or by Serial (COM1, etc). The user can set in the database which method of communications will be done for each board. The driver will handle both types of communication at the same time.
Both the Serial and TCP versions must have the same events, and methods definitions (at least those that are publicly visible).
What I did was create an interface named CommunicationsInterface
public interface CommunicationsInterface
{
event ReceiveData onReceiveData;
event SendData onSendData;
event SocketConnect onSocketConnect;
bool Open();
bool Close();
..... many more
}
I placed all of the prototype methods and events into this interface file. Next I created two more classes TCPCom and SerialCom. These new classes derive from the CommunicationsInterface.
public class TCPCom : CommunicationsInterface
{
public event ReceiveData onReceiveData;
public event SendData onSendData;
public event SocketConnect onSocketConnect;
public bool Open(){...}
public bool Close(){...}
}
-- Same for the SerialCom class as above
Now in the main application I can use either one of those classes by simply instanciating one of type CommunicationsInterface
private CommunicationsInterface _com;
public void SetComType( string comType )
{
if( comType == "TCP" )
_com = new TCPcom();
else
_com = new SerialCom();
if( _com.Open() )
MessageBox.Show("Connected");
}
Because both classes derive from CommunicationsInterface, the main application can call any of the methods without knowing anything more about the underlying class that will do the real work.
Obviously in this example, the Open() method is going to operate totally different in the TCPcom class as the one in SerialCom.
That is what an interface gives you. Plugins do the same thing, because each plugin must be of the same interface type so that the main application can call those primary methods we have to have to make plugins work, and the main application has no concern on which DLL it is working with, only that it is derived from the main Interface definition .
Hope that helps you understand what an interface is.
------
Okay, looking at your project requirements, sound fine to me, I build all of my menu and buttons from a database as well. I use the Tag property to hold special information such as the filename of the plugin to launch. So, I see nothing wrong with your approach.
I assume that all of your processing logic is inside the modules.dll
The modules.dll is referenced, and therefore all of the calls are validated during the compile. To replace the modules.dll file with a special version that has additional methods, means a recompile, and therefore the main application itself has become a special version.
Two options come to-mind. Create an interface with all possible methods and events for both the special and production versions, and just stub the special methods out in the production version.
OR
Create a generic command method like I posted earlier so that you can pass special commands to handle anything in the future.
You see, the compiler only looks at the public method prototypes of the referenced file during the compile. What the method does within each version of modules.dll is up to that file.
Hope this helps. If you are ready to get into plugins, let me know, and we will start off with creating an interface that all plugins will derive from, then we will create a simple hello world plugin, and third we will build a light weight plugin manager that will load the plugin on demand. Finally, the main application will be setup to use the plugin manager class.
Cheers,
Jerry