Doing this in .NET is actually slightly easier than in COM, in my opinion, and far more powerful. For instance, getting your COM plugins to show an interface within a dialog shown by the host application was a bit of a nightmare, and required calls to SetParent and inventive use of window styles to get working properly. This is trivial in .NET because of the Windows Forms architecture. The process of opening and inspecting DLLs in .NET is much the same.
Plugin Architecture
The best way to implement plugins in your application is with Interfaces. It is beyond the scope of this tutorial to explain interfaces, but they are in essence a contract. Any class implementing an interface must implement every member on the interface, so any application that knows about the interface knows exactly what to expect.
You start off by building a class library with the interface(s) in. Usually you would use at least two. The minimum you could have is one, which every plugin class would implement. However, in practice you generally need another interface, which the host implements so the plugins have some way of communicating back to the host application. When the interface class library has been built, you write the host application which references this library, and can inspect any number of DLLs to see if they contain classes that implement these interfaces. At this point you can develop the plugins themselves, again referencing the class library to implement those interfaces.
Comments