Dynamic Assembly or Plugin???

  • Thread starter Thread starter Matt
  • Start date Start date
M

Matt

I'm hoping someone can steer me in the right direction to try to do the
following:

I am developing an application where we receive files from customers. Right
now we receive a variety of formats. I was looking at writing some type of
base application that would allow me to add-in either new assemblies or
plugins, don't know how or which way, for different scenarios. We may
just recieve a text file so an assembly would handle everything for that or
XML and that would use yet a another assembly or a CSV and yet another
assembly. I guess I am looking at building a dynamic system that can
easily be expanded or added onto without having to continually make changes
to the base application.

Does anyone know what this type of programming is called and where I can
find articles or samples on doing something such as this? I have found some
information to believe that I would be creating assemblies and loading them
dynamically and others that talk about plugins. I have seen other
applications that do this type of bolting on.

Thanks,

Matt
 
It sounds like you want a plugin architecture. Plugins are so easy to do in
..NET that I've had plugin architectures in every major application I've
written in .NET. That may seem like overkill, and it certainly requires
extra work up-front, but it makes extending apps SO much easier. I'll add
the caveat that it makes it easier if your really think through the design.

There are a number of ways to do it, but here's the basic gist.

I usually use an XML config file to tell me what plugins to load. I have
also assigned specific directories for plugins and simply load all
assemblies from the plugins directory. It doesn't really matter one way or
the other. The XML format allows you to more easily specify extra
information about the assembly, though.

I generally create a "Plugin" assembly specific to the application. It
defines an "Application" interface which is implemented somewhere in the
main app and is passed to the plugin during initialization. This interface
provides the plugin with a way to communicate to the application. It might
use it to get access to the list of plugins for any plugin interoperability,
or to get access to information it needs to do its job.

It also defines the interface(s) used by the plugins. The plugins will
implement the interfaces provided here. This is how the application
communicates to the plugins.

You don't have to use interfaces, but I find it to be a very simple method.

The plugin assembly is referenced by both the main app and the plugins
themselves. This gives them the ability to communicate back and forth via
method calls.

Basically, you'll use Assembly.LoadFrom() to load the plugin. Once loaded,
you can then instantiate objects in the assembly via
Assembly.CreateInstance() and cast them to your plugin interfaces.

There are tons of samples on the net of how to do this. Do a search on
google for C# plugin. CodeProject also has a few different articles with
different architectures. Choose one of those or roll your own.

Pete
 
Back
Top