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.

Hagioscope

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.

Repairman

Thanks for the reply and for the welcome retag. I guess integration with Prism along with ExportFactory is the right way to go, though it seems like an overkill for a simple request as "don't add me to the container". I haven't given up yet - I'm still looking to find a more simple and elegant solution for this. – Hagioscope

Answer 2

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.

Gautama

I believe you'll agree that it's kind of silly that I implement IDisposable in order to dispose of an object sooner rather than later, and achieve the exact opposite due to the implementation of the MEF container. Not implementing IDisposable on my VMs isn't a real option since I need to do cleanup like unregistering from composite commands - if I don't do that, the VMs won't be GC'd. My views are in charge of disposing of their VMs, but either way calling Dispose() doesn't remove the reference to the object from the container, so that doesn't help anyway. – Hagioscope

I think that using my second suggestion of injecting a view model factory into every view instead of view model created by MEF should solve your problem. Obviously creating a factory for each view model becomes rather tedious but nevertheless is what I find myself doing a lot when using the current version of MEF for dependency injection. – Gautama

Answer 3

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.)

Pavement

I didn't mention it in my question, but I'm using Prism to create my views, so I can't really access that part of the code to retrieve an ExportFactory object. Even if I could, there's the problem of accessing the factory object from the place in code where I want to dispose of the view, and using an ExportFactory for every NonShared object which is very unintuitive and not doesn't seem like a good practice. – Hagioscope

@Lester: You should only use ExportFactory for objects which need to be created/disposed explicitly by the importer (which enables the creation of objects with a shorter life span than the MEF container). I'm not saying that you should use ExportFactory wherever you have a NonShared export now. – Pavement

Answer 4

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.

Hagioscope