By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,137 Members | 2,242 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,137 IT Pros & Developers. It's quick & easy.

Dynamic Assembly or Plugin???

P: n/a
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

Nov 16 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
"Matt" <md*****@sorvive.DONT-SEND-SPAM.com> wrote in message
news:eI**************@TK2MSFTNGP14.phx.gbl...
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

Nov 16 '05 #2

P: n/a
Pete,

Thanks for the quick response and I will look into plugins.

Matt
"Pete Davis" <pd******@NOSPAM.hotmail.com> wrote in message
news:SL********************@giganews.com...
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
"Matt" <md*****@sorvive.DONT-SEND-SPAM.com> wrote in message
news:eI**************@TK2MSFTNGP14.phx.gbl...
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


Nov 16 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.