Coleta de lixo ao usar delegados anônimos para manipulação de eventos

ATUALIZAR

Combinei várias respostas daqui em uma resposta 'definitiva' em umnova pergunta.

Pergunta original

No meu código, tenho um editor de eventos, que existe durante todo o tempo de vida do aplicativo (aqui reduzido ao essencial):

public class Publisher
{
    //ValueEventArgs<T> inherits from EventArgs
    public event EventHandler<ValueEventArgs<bool>> EnabledChanged; 
}

Como esse editor pode ser usado em todo o lugar, fiquei muito satisfeito comigo mesmo por criar essa pequena classe auxiliar para evitar reescrever o código de manipulação em todos os assinantes:

public static class Linker
{
    public static void Link(Publisher publisher, Control subscriber)
    {
         publisher.EnabledChanged += (s, e) => subscriber.Enabled = e.Value;
    }

    //(Non-lambda version, if you're not comfortable with lambdas)
    public static void Link(Publisher publisher, Control subscriber)
    {
         publisher.EnabledChanged +=
             delegate(object sender, ValueEventArgs<bool> e)
             {
                  subscriber.Enabled = e.Value;
             };
    }
}

Funcionou bem, até que começamos a usá-lo em máquinas menores, quando comecei a ter ocasionais:

System.ComponentModel.Win32Exception
Not enough storage is available to process this command

Como se vê, existe um lugar no código em que os controles de assinantes estão sendo criados, adicionados e removidos dinamicamente de um formulário. Dado meu conhecimento avançado sobre coleta de lixo, etc. (ou seja, até ontem), nunca pensei em esclarecer atrás de mim, como na grande maioria dos casos, os assinantes também vivem durante toda a vida útil do aplicativo.

Eu brinquei um tempo comDustin Campbell's WeakEventHandler, masnão funciona com delegados anônimos (não para mim de qualquer maneira).

Existe alguma maneira fora deste problema? Eu realmente gostaria de evitar copiar e colar o código da placa da caldeira por toda a loja.

(Ah, e não se preocupe em me perguntar POR QUE estamos criando e destruindo controles o tempo todo, não foi minha decisão de design ...)

(PS: é um aplicativo winforms, mas atualizamos para o VS2008 e .Net 3.5, devo considerar usar oPadrão de evento fraco?)

(PPS: Bomresposta de Rory, mas se alguém puder inventar um equivalente ao WeakEventHandler que evite que eu precise me lembrar de desvincular / desvincular explicitamente, isso seria legal ...)

EDITAR Devo admitir que resolvi esse problema "reciclando" os controles em questão. No entanto, a solução alternativa voltou a me assombrar, pois a 'chave' que eu estava usando é aparentemente não exclusiva (soluço). Acabei de descobrir outros linksaqui (tentei isso - parece ser um poucotambém fraco - o GC limpa os delegados, mesmo que o alvo ainda esteja vivo, o mesmo problema coms, responda abaixo),aqui (obriga a modificar o editor e realmente não funciona com delegados anônimos) eaqui (citado como incompleto por Dustin Campbell).

Ocorre-me que o que estou procurando pode ser semanticamente impossível - os fechamentos são projetados para 'ficar por perto mesmo depois que eu me for'.

Eu encontrei outra solução alternativa, então vou continuar com isso, enquanto aguarda umvoz dos deuses.

questionAnswers(4)

yourAnswerToTheQuestion