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

.net memory-leaks prism mef object-lifetime
Adi Lester picture Adi Lester · Jan 9, 2012 · Viewed 7.3k times · Source

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

Nicholas Blumhardt picture Nicholas Blumhardt · Jan 9, 2012

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.

Related questions

Implementing IDisposable correctly

In my classes I implement IDisposable as follows: public class User : IDisposable { public int id { get; protected set; } public string name { get; protected set; } public string pass { get; protected set; } public User(int UserID) { id = UserID; } public User(string Username, …

Read More
What strategies and tools are useful for finding memory leaks in .NET?

I wrote C++ for 10 years. I encountered memory problems, but they could be fixed with a reasonable amount of effort. For the last couple of years I've been writing C#. I find I still get lots of memory problems. They're …

Read More
Is a memory leak created if a MemoryStream in .NET is not closed?

I have the following code: MemoryStream foo(){ MemoryStream ms = new MemoryStream(); // write stuff to ms return ms; } void bar(){ MemoryStream ms2 = foo(); // do stuff with ms2 return; } Is there any chance that the MemoryStream that I've allocated will somehow fail …

Read More