.net - MEF keeps reference of NonShared IDisposable parts, not allowing them to be collected by GC

Question

I've encountered somewhat of a problem in MEF's part lifetime which causes memory leaks in my Prism application.

My application exports views and viewmodels with the PartCreationPolicy being set to CreationPolicy.NonShared. The views and viewmodels inherit from ViewBase and ViewModelBase respectively, which implements IDisposable.

Now, since my parts implement IDisposable, a reference to them is kept by the container, which causes them to not be released by the garbage collector. According to MEF documentation on part lifetime, this is by design:

The container will not hold references to parts it creates unless one of the following is true:

• The part is marked as Shared
• The part implements IDisposable
• One or more imports is configured to allow recomposition

How then can I make MEF not keep a reference to these parts? Is there an attribute I can use to let MEF know I don't want it to keep a reference to my part even if it implements IDisposable?

Both of the strategies discussed in the above article don't seem like good solutions for me:

• ReleaseExport requires an Export object as a parameter, which I don't know how to provide. I have the instance of my view, but there's no way for me to know what was the contract that was used to create the view. It would've been great if there was an overload for ReleaseExport which could receive any object created by the container.
• Using a child container doesn't seem like a natural option either.

Any help will be greatly appreciated.

Answer 1

Unless Prism supports some kind of lifetime for view objects, there is no solution here except to remove IDisposable from the list of interfaces exposed by the view.

There are three MEF approaches to handling this problem, all mentioned by other responders:

• ExportFactory<T>
• Child containers
• ReleaseExport()

All of them require some work on the part of the code that requests the original export - in this case code within Prism. This makes some sense, as it is undesirable for code consuming an object to have to be aware of how and when it was created.

There is no ReleaseExportedObject() in MEF because multiple (e.g. property) exports can return the same value; it may be logically possible to provide but the added complexity makes it unlikely to be addressed by MEF in the foreseeable future.

Hope this helps; I've retagged this question 'prism' as I'm sure others in the Prism community will have encountered this and be able to offer advice.