Estive investigando por que alguns dos meus controles não estão sendo coletados como lixo e notei que é fácil impedir que controles simples que herdam do ContentControl sejam destruídos. Aqui está um exemplo:

Aqui está o meu ContentControl personalizado:

 public class MyCustomControl : ContentControl
{

    public MyCustomControl()
    {
        Debug.WriteLine("Constructed");
    }

    ~MyCustomControl()
    {
        Debug.WriteLine("Destroyed");
    }
}

Agora, se eu colocá-lo em uma página como esta:

<navigation:Page x:Class="SimpleTestBed.Views.CustomControl" 
       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
       xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
       xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
       mc:Ignorable="d"
       xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
             xmlns:local="clr-namespace:SimpleTestBed"
       d:DesignWidth="640" d:DesignHeight="480"
       Title="CustomControl Page">
<Grid x:Name="LayoutRoot">

    <StackPanel>
        <local:MyCustomControl>
            <TextBox Text="{Binding SomeProperty,Mode=TwoWay}"></TextBox>
        </local:MyCustomControl>
    </StackPanel>

</Grid>

Com o seguinte código por trás:

 public partial class CustomControl : Page
{
    public CustomControl()
    {
        InitializeComponent();

        this.DataContext = new CustomControlViewModel();

        this.Unloaded += new RoutedEventHandler(OnUnloaded);
    }

    void OnUnloaded(object sender, RoutedEventArgs e)
    {
        this.DataContext = null;
    }

    // Executes when the user navigates to this page.
    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
    }



}

Então o modelo de visualização é:

  public class CustomControlViewModel : INotifyPropertyChanged
{

    #region INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged(string propertyName)
    {
        RaisePropertyChanged(propertyName);
    }
    private void RaisePropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
    #endregion


    private string _someProperty = "Initial Value";
    public string SomeProperty
    {
        get { return _someProperty; }
        set
        {
            if (_someProperty != value)
            {
                string oldValue = _someProperty;
                _someProperty = value;
                OnPropertyChanged("SomeProperty");
                OnSomePropertyChanged(oldValue, value);
            }
        }
    }



    protected virtual void OnSomePropertyChanged(string oldValue, string newValue)
    {

    }


}

Agora, quando eu navego para longe desta página e tento coletar lixo com GC.Collect (), desde que eu não tenha feito alterações no texto na caixa de texto, o ContentControl e Page são destruídos conforme o esperado pelo GC. Mas se eu editei algum texto e naveguei para fora da página e tentei GC.Collect (), o ContentControl não obtém o lixo coletado.

Alguém pode explicar esse comportamento?

Na verdade, você pode forçar o GC a coletar o controle 'movendo' o Modelo do controle ao descarregar:

  void MyCustomControl_Unloaded(object sender, RoutedEventArgs e)
    {
        Debug.WriteLine("MyCustomControl Unloaded");
        ControlTemplate oldTemplate = this.Template;
        this.Template = null;
        this.Template = oldTemplate;
    }

Presumo que isso destrua a árvore visual atual, perdendo referências do primeiro componente da árvore para seu pai (o controle personalizado). Certamente força o controle a chamar OnApplyTemplate quando o controle é recarregado.

Esse é o padrão correto para o desenvolvimento de controles do Silverlight sem vazamento? Nesse caso, me parece um pouco estranho que o modelo não seja descartado automaticamente quando o controle é descarregado.

Uma boa explicação desse comportamento seria muito apreciada, pois vai direto ao cerne do ciclo de vida dos controles do Silverlight.