Chris Cyvas

MEF is the Managed Extensibility Framework, which is a project out on CodePlex. The aim of the project is to allow greater reuse of applications and components. Microsoft has said that they will be using it in the next rev of Visual Studio – so there’s some buy-in there.

In dashCommerce we allow you to drop in your own providers for Tax, Shipping, and Payment. There are others coming, but one thing that seems to be tripping people up is how, exactly to pull that off. Now, I think it’s pretty darn easy, but I built it, so it makes perfect sense. In addition, people are doing some pretty amazing things with dashCommerce and the application is growing – quickly. And there is a ton of room for additional functionality and flexibility.

With that in mind I started playing with MEF to see what the basic facilities were. And I had something in mind that I wanted to test right off the bat – dropping assemblies into the bin directory and see if they would auto-magically appear for use by the application. I built a windows service a few years back that allowed you to do just that – it was pretty slick, but I never went any further with it. Well, MEF allows us to make the shift from statically compiled applications to dynamically composed applications. There is a lot of power there. A lot.

So, with my minimal goals in mind, I set out to create a simple Cashier application that would try to charge something (actually, it doesn’t charge anything, but it says it does). On the first pass through, there are no classes that implement IPayment so it looks like this:

If I then browse the solution and drop the Payment assembly into the Cashier\bin\Debug directory and press the space bar, I will see this:

You can see that without stopping and restarting the application, it has recognized that I have dropped in an assembly that has a particular type of export in it:

  [Export(typeof(IPayment))]

I can then browse to the Authorize assembly and drop it into the same location and press the space bar once again and I see this:

Now it recognizes that it has two classes that implement IPayment and it is exercising the Charge() method on each of them. Now, if we couple this with dropping the configuration controls into a specific location, we will get rid of the registration process that currently has to happen in dashCommerce and we will be on our merry way to composing dashCommerce in a highly flexible way! Very sweet!

[UPDATE:]

I did try to upload the sample solution, but WordPress doesn’t allow the uploading of .zip files. So, I had to do a little thing to get it to work. You can get it here.