MEF keeps reference of NonShared IDisposable parts

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

You should create these instances via an imported ExportFactory<T>. You will then have the necessary control to dispose of them via ExportLifetimeContext<T>.Dispose().

However, this is only available out of the box in the next .NET version (4.5) or in the latest MEF preview releases on codeplex. (In older versions of MEF the same functionality was implemented as a sample and was called PartCreator, as described in this blog post.)

Answer 2

All the other answers provide good ways to circumvent this issue, but what I ended up doing eventually was using my own custom interface, ICleanup, instead of IDisposable. This of course may not be suitable for everyone.

Answer 3

When you implement IDisposable you are sort of saying that the type should be cleaned up in a deterministic way (by calling IDisposable.Dispose and not randomly when the garbage collector decides that it is time.

In your case the view models will only be disposed when you dispose the container which is probably not what you want to do. To get around this I see two possible solutions:

• Don't implement IDisposable on your view models. Apparently you don't care about when they are cleaned up anyway so why make them IDisposable?

• Instead of letting the container create each view model non-shared you could use a shared view model factory class. You can then inject that class into owners of view models to allow the owners to explicitely create view models. Presumeably these owners would also know when to dispose the view models.

Basically, if something is disposable that should also be a sensible point in your code where you need to dispose what is disposable.

Answer 4

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.