Although the .Net Garbage collector reduces the need to concern yourself with memory you still need to pay attention to memory consumption and the causes of memory leaks or GC Roots. This will ensure you have well behaving & efficient application.
Libraries/Controls which I recently used that caused memory leaks:
a) Silverlight 4 runtime:
Some major memory leaks have been resolve with the Runtime drop in early 2011. Make sure you are using the latest version.
b) Caliburn Micro:
Make sure you use the latest version of the source code from codeplex since a major memory leak was fixed on May 6 2011.
c) Telerik controls:
Silverlight Telerik Controls with memory leaks.
d) Silverlight 4 Toolkit Controls:
A good example of a control with memory leaks here was the Context menu control. I resolved the memory leak in the ContextMenu control by implementing the patch in the context menu source code and manually calling Dispose() on the Context Menu control in the View's unload event. Keep your eye on the patches available for this control and various other controls which also have memory leaks!! (sigh)
Patches for the Silverlight 4 Toolkit.
Additional causes of memory leaks:
1) If you are using MVVM Shared resources declared in your Views will create GCRoots. Make sure all your shared resources are declared in your App.Xaml only. An example of this is when you are Merging your resources unecessarily in your View eg:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Themes/XXX.xaml"/>
<ResourceDictionary Source="/Themes/YYY.xaml"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</UserControl.Resources>
2) Timer callbacks. Creating a timer with an event that keeps ticking for infinity will create this issue. Make sure you call the Dispose() on the Timer when you unload the View.
3) Not unsubscribing from a Rx feed. Rx creates strong references under the hood.When one ViewModel subscribes to a feed from another view model a strong reference is created.
4) Strong references between shared objects and Service Models.
5) WPF Behaviours : By unwiring the behaviours for the Views in the Unload event using a helper class this issue was resolved.
6) WPF Fluid Move behaviours : Unfortunately there was no clear resolution to this.
7) Interaction Event Triggers which use Expression Blend's Interaction library to raise event triggers. IF these triggers use a ControlStoryBoardAction which references a static resource containing an animation that has a RepeatBehaviour set to Forever, this will cause a memory leak.
8) Each ViewModel needs to implement the Dispose Pattern. When the dispose for a ViewModel is called it needs to call Clear() on all observable collections that have been bound to child view's(user controls). This will ensure that the View's are unloaded.
9) When using MEF make sure understand how your container setup affects the lifetime of your application's objects. There may be scenarios where you will manually need to release your Exports.
RedGate Memory profiler:
This is a great tool although it only shows you the main memory leaks so you may think you have resolved all of them only to find that more leaks pop out of the woodwork. The ANTS Redgate Memory Profiler is able to provide a graphical display of strong references between objects on the managed heap.
