How to Make a "Dashboard" Utility that Accepts Modules/Add-Ins

I hope this question makes sense. Basically, I am looking for a set of guidelines, or even a tutorial, that will show how to make an application that can easily add and remove "modules" or "add-ins"

For example, in Microsoft Office, you will commonly see programs that you can download and install and they will just add an extra tab into Microsoft Word (for example) that will implement some new feature.

I have several applications that use basically the same data source, and I'd like to consolidate them and also leave open the possibility of adding more functionality in the futur开发者_开发知识库e without 1. Requiring a brand new install and 2. Tweaking every piece of my code.

I'm looking for a place to start, mostly.

Thanks in advance.

**

Edit: To elaborate a little more... The thing I have in mind specifically is an application that accesses a large set of data that is stored in text files and uses some of the data to create a few graphs and maybe some tables. I'd like the ability to add different graphs in the future using the same data. So, you can click Button_A and generate Graph_A, then a few weeks later, you can click Button_B and generate Graph_B.

It would be really nice if I could come up with a way that only required reading the data from the file(s) once, but I know that would involve having to adjust my DataReader class a bit.

---

One place to start would be to define an interface for your future modules, and build a utility that scans all the dll's therein, looking for classes that implement said interface.

Once you've found supporting classes you can create instances at runtime and add to your application. That's a common idiom in .NET for supporting "plug-ins"

The Activator class is a common way to create instances from a Type at runtime.

http://msdn.microsoft.com/en-us/library/system.activator.aspx

It's hard to give more details without more info in your question. Can you elaborate a bit?

---

Take a look at the Composite Application Library from Microsoft.

It is aimed at WPF but you could get some ideas from there.

---

As Adam said, the first thing to do is define the interface for your plugin modules - what can they expect to receive from the container, and what methods must the container be able to call?

As far as the container itself goes, I'm partial to MEF as a location technology; you can create catalogs and re-compose the system when new DLLs are added. I've built a similar system to this for parsing dissimilar files, and the composition capabilities of MEF are awesome for runtime discovery.