In C#, is it necessary to assign an object variable to null if you have finished using it, even when it will go out of scope anyway?
For an object which has to implement IDisposable, as a practice I set all members to null in the implementation of IDisposable.
In the distant past I found this practice drastically improved the memory consumption and performance of a .NET Compact Framework application running on Windows Mobile. I think the .NET Compact Framework at the time probably had a very minimalistic implementation of the garbage collector compared to the main .NET Framework and the act of decoupling objects in the implementation of IDisposable helped the GC on the .NET Compact Framework do its thing.
An additional reason for this practice is after IDisposable has been executed on an object, it's actually undesirable for anything to attempt to use any of the members on a disposed object. Sure ideally you'd want an ObjectDisposedException out of an object which has been disposed when something attempts to access any of it's functions, but in place of that a NullReferenceException is better than no exception at all. You want to know about code messing with disposed objects as fooling around with unmanaged resources that have been released is something that can get an application into a lot of trouble.
NOTE: I'm definitely not advocating implementing IDisposable on an object for no other reason than to set members to null. I'm talking about when you need to implement IDisposable for other reasons, i.e. you have members which implement IDisposable or your object wraps unmanaged resources.