Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,130 | Comments: 45,556

filter by tags archive

How to write MEF in 2 hours or less

time to read 2 min | 361 words

It took me a while to get around to this blog post, I promised Glenn that I would write it ages ago.

The title of this blog post, which is admittedly provocative, refer to a (I believe intentional) misinterpretation of a comment of mine in a MEF talk. It might also explain my general attitude about software in general.

MEF is a pretty big library, and it does a whole host of things. But when talking about it, there are specific features that keep getting mentioned over and over, probably because they are:

  • Really nice features.
  • Demo very well.

A good example of that is MEF ability to import new types on the fly. It is something really nice, but it isn’t something that is really impressive to me. Doing dynamic loading isn’t really hard. That has led me to make the comment that turned into the title of this post.

The actual comment I made was: “I can implement this feature (dynamic loading) in less than two hours.” The problem is that that was interpreted as saying that I can implement MEF itself in 2 hours (just to be clear, it isn’t possible). What is possible, however, is to implement interesting parts of MEF for a particular scenario in a short amount of time.

In fact, most of the time, I can implement the features that I find attractive in some software (not limited to MEF) faster than I can learn how to use that software in the first place. Granted, it may be a single purpose, only-works-under-the-following-set-of-assumptions implementation, but it will work, it will be faster out of the gate and it will limit the number of dependencies that I have to manage.

It is something that you have to consider, because sometimes you want to put those responsibilities at the hands of some other party because you don’t want to deal with that. Sometimes you explicitly want to do it yourself because giving up control on this thing (or adapting to the way some library does it) is not acceptable.


Vitaly Stakhov

Reasonable point. However other team members may be not so happy to gettting used to ad hoc frameworks/libraries that grow right and left on the project. Good thing to keep in mind as an option though.

Andrey Shchekin

I tend to do it the other way around -- if there is an existing library, I will generally throw away my code that does the same, take the library, tweak its API into submission and use that.

Because it saves on maintenance, unit-testing, and libraries tend to evolve themselves, growing new features just when I need them.

Alex Simkin

Fortunately MEF will become a part of the framework - the dependency that we have anyway.

Ryan Riley

Your previous post from 2007, while effective, isn't quite "from scratch" which is what I thought you meant (though you never said so). I guess the question is then, would you use MEF or use your own hot swap code? What are the advantages and disadvantages of each? I know others are writing on this, but I'm interested in your take.

Ayende Rahien


that depends on too many variables. As for "from scratch", I strongly believe that working on the naked CLR is sacrilege.


I strongly believe that working on the naked CLR is sacrilege.

You should really do an audit at my company then....

Got blamed because I used a javascript BSD licence library haha

Julian Birch

This does, of course, assume that there aren't subtleties to the framework that you don't understand yet. After all, I doubt you'd apply this argument to Castle Windsor or NHibernate. The "interesting part" of Castle Windsor is constructor injection, and that's pretty easy to write from scratch.

It's only later that you discover that your two hour IoC container doesn't really cut it in the more complex scenarios. Equally, I imagine it would take a while to start to really appreciate the subtleties of what Hammett's solving.

Glenn Block

Finally got around to finding this.

Oren, I don't have any issue with anything you said above. You may very well be able to implement your own feature set for your apps in a shorter amount of two. Certainly MEF supports many scenarios some of which you might never need, though others you may be discarding prematurely.

The thing about MEF though is it is not designed for you. And what I mean but that is not being tongue and cheek. I mean, it's main goal is not for the individual it is for the ecosystem.

  1. It is designed for an ecosystem of extenders. It introduces a common approach for building that ecosystem across many applications.

  2. It is designed to support some very large extensible applications like Visual Studio.

Albeit the above being the case, we've worked hard to ensure that you can "turn up the dial" of complexity as you need it, and can get off the ground with a minimal set. You don't need to be Visual Studio to take advantage of MEF.

I can't help but think that you are oversimplifying the capabilities MEF provides, and that those features would not be so trivial to implement, however I am not going to go there.

Jon Flanders

So why not build your own transitors, CPUs, RAM, HD, and video card?

Ayende Rahien


Those don't take two hours or less

Jon Flanders

But even if they did - I would guess most of us would still buy from a vendor.

I know from experience that you can whip together a dynamic loader in a short amount of time. But it won't have the full feature set of MEF - it won't be the same framework that other people use (and used by Visual Studio, the SQL Modeling Tools etc).

There is a benefit to resiting the NIH urge:

1) How long will it take the next person who builds on your framework to learn it (once MEF become part of the framework - new developers should automatically understand how to use it).

2) How easy will it be for you to maintain? How many new features will get added to MEF over time?

I am guessing you know these things - but perhaps others reading your blog don't.

Comment preview

Comments have been closed on this topic.


  1. How to waste CPU and kill your disk by scaling 100 million inefficiently - one day from now
  2. RavenDB Conference 2016–Slides - about one day from now

There are posts all the way to Jun 01, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats