Resolved usercontrols never go

Aug 2, 2010 at 8:56 AM
Hey guys, I'm having a bit of an issue with my Silverlight Application that uses Prism. Here's the deal: What I do is, everytime a user opens a window in my application I resolve a new Usercontrol with it's own ViewModel. So basically a user clicks something in a grid and it opens in a detail screen. The reason I do this is because I want to make it possible to open multiple detail screens at the same time. This way, it's possible for a user to open two different detail screens of the same type, let's say a contact for example. The problem is that these detail screen Usercontrols, their ViewModels and all the data they're holding will exist as long as the application does. So my question is this: Is there any way to "unresolve" these usercontrols. To make the garbage collecter pick them up and get rid of them? Because right now there is some serious memory issues going on if a user uses my application for longer than a few hours. Thanks for taking the time to read this.
Aug 3, 2010 at 10:13 PM


I do not know your exact scenario, but there is no Unresolve method in Unity, because when you call to the Resolve method it does not keep a reference of the new instances.

If you use the Unity RegisterInstance method to register views, please take into account that this is not the most recommended approach. Therefore, if you are doing it to get them available from different locations, you could switch to use ViewDiscovery, which allows you to discover views in a cross-module way, and does not keep alive an object reference. 

In Prism there are different approaches to make a view either visible or non-visible. But, in this particular case, the correct option would be to remove the detail views from its region when users close them. This way, the garbage collector should be able to collect the detail views. This might be achieved in your scenario by using the following code line:


On the other hand, there are two known issues related with memory leak(s), the first one is when using DelegateCommand (it was solved in Prism 2.1 & later), since it keeps an instance of the bound control and the view that contains such control is not released. And the second one is when removing a view that contains child-regions.

For more information about these topics, you could take a look at the following posts in the Damian’s Blog:

If it does not help in your scenario, please consider sharing any other relevant information that might help to clarify this situation.

Please let me know if this helps.

Fernando Antivero

Aug 4, 2010 at 11:19 AM

Hey fantivero,

I see what you're saying, and it seems very helpful. I will play around with it and see if I can make some progress. I will keep you updated and tell you if I have any further issues. Thanks a lot!