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,124 | Comments: 45,481

filter by tags archive

Reading MEF code

time to read 3 min | 401 words

Okay, here is the deal. There is a feature in MEF that I find interesting, the ability to dynamically recompose the imports that an instance have. Well, that is not accurate. that doesn't really interest me. What does interest me is some of the implementation details. Let me explain a bit better.

As I understand the feature, MEF can load the imports from an assembly, and if I drop another file into the appropriate location, it will be able to update my imports collection. Now, what I am interested in is to know whatever MEF allow me to update file itself and update it on the fly. The reason that I am interested in that is to know how this is done without locking the file (loading an assembly usually locks the file, unless you use shadow copy assemblies, which means that you have to use a separate AppDomain).

As you can imagine, this is a very specific need, and I want to go in, figure out if this is possible, and go away.

I started by checking out the MEF code:

svn co https://mef.svn.codeplex.com/svn mef

I just love the SVN integration that CodePlex has.

Now, the only way that MEF can implement this feature is by watching the file system, and that can be done using a FileSystemWatcher. Looking for that, I can see that it appears that DirectoryPartCatalog is using it, which isn't really surprising.

But, going there and reading the code gives us this:


Note what isn't there. there is no registration to Changed. This is likely not something that MEF supports.

Okay, one more try. Let us see how it actually load an assembly. We start from Export<T> and GetExportedObject() which calls to GetExportedObjectCore() which shell out to a delegate. Along the way I looked at CompositionException, just to make sure that it doesn't have the same problem as TypeLoadException and the hidden information, it doesn't.

I tried to follow the reference chain, but I quickly got lost, I then tried to figure out how MEF does delayed assembly loading, to see if it is doing anything special there, but I am currently hung at ComposablePartDefinition.Create, which seems promising, but it is accepting a delegate and no one is calling this.

So this looks like it for now.


Steve Degosserie

How about in constructor of AttributedAssemblyPartCatalog(string codeBase):

var assemblyName = new AssemblyName();

assemblyName.CodeBase = codeBase;

Assembly assembly = Assembly.Load(assemblyName);

this._assembly = assembly;

Ayende Rahien


You are probably right, I hoped for some fancy work there, though

Steve Degosserie

Do you think it would be possible to support dynamic recomposition with Windsor ?

Ayende Rahien


Sure, it is pretty easy, you need to write a facility that keeps track on that, though, and respond to changes to ComponentStatusChanged.

The problem is that MEF doesn't have the notion of lifetimes, and Windsor does, so you need to do some fancy footwork there to get it to work in all situations

Steve Degosserie

Interesting, I was thinking about components or sub-systems that can be started / stopped on the fly (as long as they are not a vital part of the application => a component exists that has a mandatory dependency to it) ... considering that most applicative components / services are singletons.

Ayende Rahien


Check my post about components about a week ago, it talks about that.

Steve Degosserie

Exactly ! Have you seen the presentation of Juval Lowy touting WCF as a better .NET ? As he says, WCF offers you process isolation at the class level ... maybe an interesting option?

Ayende Rahien

I heard of that, I think that he is being grossly exgagerating. WCF is really slow.

Something like five orders of magnitudes compare to plain .NET

Steve Degosserie

That's the main downside, which might be adressed by in-process transport like www.codeproject.com/.../NullTransportForWCF.aspx. Haven't tested it extensively but when you think of it, WCF has all the infrastructure (and more) that you need to implement what you describe in your post.

James Kovacs

The fundamental problem here is that .NET doesn't support dynamic assembly unloading. You could reload the assembly, but you would never be able to recover the memory used by the old one. One of the main use cases of such as feature is live updating of a long-running application and gradually leaking memory in the form of unreferenced assemblies, JIT'd code, and related data structures doesn't seem like an acceptable story to me. So work needs to be done at the CLR level before a framework like MEF can implement this for the in-process case. WCF or a cross-app-domain plug-in system are possible solutions, but - as Oren mentions - they're orders of magnitude slower than in-process and therefore aren't usable for general composition.

Glenn Block

You can achieve the functionality by setting an app domain to shadow copy (I just tested it). With shadow copying the assemblies won't be locked and you can update in place. The caveat is this won't remove any types that are loaded in memory, BUT it will allow you to update which types are available to the container as when the catalog changes, recomposition will occur. Ping me if you want to chat on this.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 15 hours from now
  2. The design of RavenDB 4.0: Physically segregating collections - about one day from now
  3. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  4. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now
  5. The design of RavenDB 4.0: Voron has a one track mind - 7 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    03 May 2016 - Making Lucene reliable
  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