Silverlight: Популярный вариант утечки памяти связанный с динамически изменяемым деревом элементов приложения Silverlight.

Нужно помнить следующий вариант утечки памяти, т.к., как мне кажется, он один из самых частых.

 

Вы создали элемент. (Все! Забыли в WPF / Silverlight слово "контрол"  ).

Вы добавляете это элемент динамичеки в дерево элементов приложения Silverlight.

По действию пользователя вы заменяете этот элемент его новым инстансом (экземпляром).

 

Все красиво работает, все заменяется и потом удаляется сборщиком мусора, но до тех пор, пока вы не привяжете методы экземпляра вашего элемента, как обработчики событий элементов, постоянно находящихся в иерерхии элементов вашего Silverlight приложения.

Например, очень часто нужно реагировать на события Application.Current.RootVisual.

 

! Будте внимательны. Как только вы начинаете использовать элемент, как динамически добавляемый / заменяемый / удаляемый, то вы больше не может (не имеете права) привязывать методы его экземпляра к событиям элементов постоянно находящихся в иерархии приложения Silverlight, т.к. в этом случае удаленные / замененные экземпляры вашего элемента не будут уничтожатся сборщиком мусора благодаря механизму событий в .NET Framework.

 

Вариантов обхода этого ограничения много, поэтому используйте нужный вам по обстоятельствам.

Например, можно использовать статические методы для обработки событий и статическую переменную для передачи нужного состояния.

Или используйте слабую ссылку – WeakReference

Чтобы копнуть глубже есть статья Слабые события в C#.