Yes, to add features. On of the important point is: the
host application is developed by one party, but some plug-ins can be developed by others, such as users or 3rd-parties.
I don't know why explaining the uses. Isn't that obvious? It can be used nearly anywhere. Do you know the Browser plug-ins? Now, look at some advanced text editor. A plug-in can provide syntax coloring for a particular programming language, invoke a compiler, present compilation results in a way adequate for this language. A support for every particular language can be a separate plug-in, or one plug-in can contain several implementations, for example, for a set of languages. A host application does not have to be a UI application. It can be a console-only application, service, even a driver.
From the standpoint of .NET, the plug-in model is pretty interesting. A host application should define one or more interfaces to be implemented by some plug-ins. I will call them
plug-in interfaces. This is something which always needed. In some cases, the host application itself needs to provide some interface to the plug-in implementations. For example, in case of the editor, this application should provide some interface, and implemented it, to give plug-in some access to edit buffer; this way, the plug-in could read text entered by the user or generate some text. What to generate "knows" just the plug-in code, calls interface methods, and how to insert the generated text into the edit buffer is "known" only to the host application which implements this host interface.
Compilation with the definition of interfaces (interfaces, not their implementations) is pretty interesting. Usually, you define some assembly, and define interfaces there. This assembly is referenced by both host application and plug-ins. Less people understand that it's possible to define everything directly in the host application. The assembly of this application can be referenced by plug-ins just as well. There is no circular dependency here: compilation of plug-ins depends on host application assembly, but plug-ins are loaded during run time using Reflection.
I shared a lot of detail on development of plug-in architectures and implementation in my past answers:
AppDomain refuses to load an assembly[
^],
code generating using CodeDom[
^],
Create WPF Application that uses Reloadable Plugins...[
^],
Dynamically Load User Controls[
^],
C# Reflection InvokeMember on existing instance[
^],
Projects and DLL's: How to keep them managable?[
^],
http://www.codeproject.com/Answers/443680/Gathering-types-from-assemblies-by-its-string-repr#answer1[
^].
This is pretty interesting stuff; please take a look.
—SA
Submit an article or tip