Venendo dal mondo VB, la regola migliore che c'era per liberare memoria era quella di appicciare a fondo funzione - dove occorreva - un bel set x = nothing, così che oggetto particolarmente pesanti venivano scaricati dalla memoria e niente problemi di appesantimento del pc o crash inattesi, overflow ecc. ecc.

Il .Net framework sicuramente ha cambiato molto in questo, grazie all'implementazione della Garbage Collection (alias GC), una specie di spazzino h24 che gira per il framework e butta via quello che non serve.

Tuttavia, secondo me, Microsoft non è stata molto chiara su come e quando questo spazzino lavora, ma soprattuto su come il codice in realtà dovrebbe essere scritto affinchè la GC faccia correttamente il suo lavoro. Soprattutto perchè credo che il grosso dubbi lo lasci il fatto di quando o di quante volte il GC giri all'interno della nostra applicazione (il Garbage Collector non lavora più per numero di istanze che conta x - 1 ad ogni nothing).
In realtà a quest'ultima domanda non c'è una risposta precisa. Può essere 0 come anche 10 o 1000. Dipende da quante risorse la nostra applicazione consuma, da quanto stress provoca in generale sul framework. E' un concetto di autoregolamentazione, dove il Garbage Collector analizza solo gli elementi creati dall'ultima volta nella quale ha fatto pulizia.

Affinchè tutto funzioni correttamente, sarebbe sufficiente l'implementazione dell'interfaccia IDisposable e annessi e connessi; ma cosa succede se la nostra funzione utilizza degli oggetti che non implementano questa interfaccia?
Allora mi è venuto l'atroce dubbio, devo o non devo mettere un x = null per liberare memoria e marcare l'oggetto come "fuori uso" così che il GC al prossimo giro lo toglie di mezzo?

Ecco allora che ho incominciato a rileggermi tutti gli articoli di MSDN, spezzoni di codice, post vari e la sintesi è che impostare una variabile a null non serve a molto, anzi a niente.
Infatti una variabile locale, non appena esce dalla funzione, esce dallo scope, quindi non è più raggiungibile ne dallo stack ne dall'heap, ergo il GC può tranquillamente sbarazzarsene.

Diverso è per un campo. Tecnicamente anche per il campo si potrebbe evitare il null, ma secondo me quando il campo contiene oggetti di un certo peso, un null esplicito, credo che male non gli faccia.
Attenzione però a non riutilizzare il campo, che la sua condivisione nella classe lo rendo soggetto ad errori di questo tipo. Basta quindi anche una sola referenza viva nell'heap o nello stack per un campo impostato a null, che il campo comunque continuerà a contenere il nostro oggetto.

Non voleva questo essere un trattato sulla distruzione degli oggetti, ma un semplice post a "memoria" di quando non devo mettere x = null.
Spero di aver letto bene e interpretato tutto a dovere. Se ci sono errori, visto che nessuno è perfetto, se li segnalate è meglio per tutti, me compreso.