.Net plugins architecture question

Question

I'm developing an app for a client and am implementing a plugin architecture. There are numerous discussions and examples here and elsewhere that have helped me with the basics, and I have a working prototype.

At startup, I'm iterating over the assemblies in the plugins folder, looping over the types in each, and creating an instance of those types that implement my plugin interface. I'm using the "Name" property of each type to populate a menu pick on the main form, but I'm not really happy with doing this for two reasons:

1. I think I can get the name that I'm interested w/o having to create an instance, perhaps with Attributes? Not having much experience with any of this, I'm not sure how to make this work or indeed if this is how it can/should be done.

2. Given a set of N plugins, my app may not require an instance of all of them during any particular run, but may require M instances of one of them, so it doesn't make any sense to me to create instances at load time.

Can someone help me understand the best way to architect this?

Much thanks!

Bo

Answer 1

Yes, you can use attributes. Attributes are available on Types, versus instances of types. The catch is that you have to iterate over all of the types in all of the assemblies to see if your attribute is present. This isn't overly complex but can be problematic if you are missing any dll dependencies.

On a side note, have you investigated MEF? It's part of .NET 4 out of the box and handles a lot of this type of thing for you.

Answer 2

I wrote an article about making a plugin system a couple of years ago: http://www.codeproject.com/KB/macros/pluginsystem.aspx

Gotchas:

• You should scan all assemblies after your attribute in a separate appdomain. Since they cannot be unloaded.
• If you want to be able to unload plugins, you need to load each plugin in a separate appdomain.
• Create an exception strategy before you do anything else.
• Try to use an existing plugin framework if you can