Develop Reference

Implementing Configurable Factory Pattern

Existing Implementation:
I have implemented factory pattern for DB connection. I am having three DB like sql,oracle and sybase. All three classes like sqlConnector,OracleConnector and SybaseConnector has implemented in Iconnect interface and in the factory method i have created the object of these concrete classes(sqlConnector,OracleConnector and SybaseConnector) based on switch case and returned specific object.
Scenario:
I want to modify this factory pattern and want to remove all switch case from factory method and want to configure through config file/xml and also without using reflection and spring.net. Suppose tommorow i introduce new db type , i don't want to change the code.I will make entry in the config/xml ,it should returned the object to client without changing factory.
Question:
How i can implement configurable factory pattern means suppose tomorrow introducing new db type like "MySql", i don't want to change the code of factory.

This is a very broad question, but I think that the technology that will best serve you is Managed Extensibility Framework, or MEF.
MEF is an integral part of .NET that allows you to include additional components into your solution without having to know what those components are beforehand. MEF automatically discovers and includes components into your solution after your solution is built.
You define the points where your solution can be extended; each component is written to take advantage of those extensibility points; MEF ties them together automatically.
If you have used an Inversion of Control framework, like a Dependency Injection library (Ninject, Castle Windsor, SimpleInjector, etc.), then you have already done something a little like this, and the concepts should be somewhat familiar to you.
Explaining it and showing you how to use it will take a book. However, I'm reasonably certain that it will solve your problem best. There are books, blogs, videos, and many, many examples.

Dynamic object instantiation for plugin system in .NET

I'm developing a system which needs to support customization via a plugins module. I'm coding against interfaces so that plugin code only needs to implement these interfaces in order to be able to plug into the system.
// for illustration purposes; not actual code
public interface IPluggable
{
void Setup(PluginConfig c);
bool Process(IProcessable p);
}
I read from configuration which plugins need to be loaded, where the assembly name and fully-qualified type name are specified.
<plugin assembly="Foo.Bar.PluginAssembly" type="Foo.Bar.Plugins.AwesomePlugin" />
Where the type Foo.Bar.Plugins.AwesomePlugin implements IPluggable and is contained in the assembly Foo.Bar.PluginAssembly.dll. With this information I proceed to create instances of the required plugins.
IPluggable plugin = (IPluggable)Activator.CreateInstance(assemblyName, typeName).Unwrap();
So my question is threefold:
What would be a recommended pattern for a plugin system? Does the approach I'm taking make sense or are there any obvious flaws/caveats I'm missing?
Is Activator.CreateInstance() a good choice for dynamically instantiating the plugin objects?
How can I be more specific about the assembly to load and its location? Say, if I want to load plugins only from assemblies located in a .\plugins subfolder.

Answers to your questions, in order:
I like this and I use patterns like this when I need to write plug in components. Other people recommend using various frameworks - I know that MEF is very popular. But I find that using the .NET framework is easy enough for me, and learning the MEF framework is just another thing I need to learn and remember. It's probably worth a try but up to you.
I've always used Assembly.CreateInstance, but the difference is probably not going affect you (Difference between Assembly.CreateInstance and Activator.CreateInstance?)
You simply use the System.IO namespace. The DirectoryInfo class has a method that enumerates all the files matching a given pattern (presumably *.dll). For each match I'd use System.Reflection namespace to interrogate and find any types that implement your interface, and then CreateInstance.
Just on MEF, my opinion is this: if I were going to be using a large, manageable and flexible plug-in system on a number of systems or projects then I'd be very interested in it, leveraging the work that other people have done to save time and avoid common pitfalls.
If I were writing a very simple, one-off plug-in system and I know the basics of how to do so using the .NET framework, I'd skip the overhead of learning MEF and write the code. I could write a reasonable plug-in process in far less than an hour, but after downloading, referencing, attempting to configure MEF - I doubt I'd have anything to show for it.

Does a composable Application necessarily imply a Plugin based architecture

I am currently working on an application and would like to add new functionality to it.
One would be to update the application's code directly.
Another would be to offer an extensibility layer where new features will be added to.
Having read multiple posts on Plugin architectures and using MEF for creating composable apps, i am a bit confused whether the 2 terms actually mean the same thing, and if not in what do they differ?
Also, i am interested to know of any good design solutions that assist in "opening up" my application to allow easier expansion in the future (new futures can be added "as an extension")

You will definitely need a plug-in based architecture to have a generic extensibility framework.
However, you do not necessarily need a Dependency Container or MEF.
It may be as simple as defining an IPlugIn interface and scanning assemblies for types implementing the interface. Then instantiating an instance of the type to get going.

Changing winform app for specific clients

I have a winforms app. I give it to three clients and each one wants a small tweak or customization specific just to them. To accomplish this, I'd have to keep a separate version just for each client. I may wind up having many versions doing it this way. I thought dependency injection would be how to handle this but I hear you have to register your dependencies in the main method and you'd still have to add a reference to each clients DLL so I'd still need different versions. What is the preferred object oriented way to handle this? Any better ways to handle this?

You can use a Plug-in patten to load assembly at runtime: (from link)
Separated Interface (476) is often used when application code runs in multiple runtime environments, each requiring different implementations of particular behavior.
Most DI frameworks provide this functionality. You can search at get lots of Examples for framework you choose - if you don't want to roll your own.
Ninject
MEF

You can use a configuration file to configure your DI container, so that you can reuse the same binaries with different configuration files to implement the different customizations. But you need to be sure that you thoroughly test all of your different configurations. Slightly different versions of the same application are not trivial to maintain without causing unanticipated breaks.

Depending on the nature of the customixations, you might be able to capture all relevant modifications into a distinct part of the project (as opposed to keeping them spread all-over the project). If you can (e.g. a filering functionality is provided by the client), you can then load a DLL dynamically (e.g. based on a config file) and allow the functions in the DLL to perform the necessary functionality that accomplishes the customization (based on parameters provided by the main code).
This way you provide pre-defined hooks to your code that can be changed dynamically (even if only to load the dlls at startup time) as per the need of the client. You can separate these DLLs into multiple ones if there are distinct features that the clients want to change, but not necessarily all of the clinets all of the features. Then you can provide a "default" version of the DLLs.
Who develops the hooks is dependent on your setup with the clients.
Make sure you provide adequate documentation on how these hooks supposed to work -- even if you end up developing them.

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 future 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.