Wally writes about the practice of Disposing objects and then setting them to null/Nothing. Now in general the second step is redundant because while it does (or can, depending on other references) make the object eligible for collection, you never know when that collection is going to occur. In most cases the code is written such that the variable is well out of scope by time the next collection occurs.
So it is kind of like throwing salt over your shoulder before you put some into the pasta in the kitchen.
Having said that there are instances where setting objects to null is a good practice. The first one is nulling out fields that have objects that are no longer in use and probably won’t be in the future. This makes them collectable.
Inside the scope of a method with locals, the case is so much weaker. If you can predictably rely on allocating enough objects to force a garbage collection then setting locals to null that are no longer in use would mean they get collected. But if you are allocating that many objects freeing up one isn’t likely to make a huge difference, and if you needed it to be freed up then you would have implemented the IDisposable pattern anyway – right? Right.
One myth is that you should still set RCW’s to null. This isn’t true either, if you want to release them early call Dispose (if they have it), if not, consider using Marshal.ReleaseComObject(…).
Keep in mind that this won’t necessarily release the COM object because there might be other references to it – but if you called it repeatedly you could unravel the ref-count and force it out (dubious practice warning). In general its the job of the allocator to release the resources that they allocate.