setting a object to null vs calling a dispose() function

dispose is the best when cleaning the resources rather than setting to null.......

but as .net has inbuilt garbage collector, you don't even need to worry about that.....either you set it null or dispose manually, the object will be cleaned with just a bit of difference in time........

when there is a need of resources, GC is called automatically.........

Yes and um, no. When the garbage collector runs, it looks at all object reference variables to see if , well, they reference an object. Then it has to see if the object is actually in use. For eaxample, you might have an object foo that contains a reference to object bar. The reference variable to foo was on the stack, so it is gone now, but the object foo is on the heap, so it still has a reference variable to bar. The garbage collector puts bar in a queue while it continues to look because it might also be referenced somewhere else. If it determines that the object is NOT referenced anywhere else, then it is put in the "unreachable" queue. then the garbage collector (GC) stops running.

The next time the GC runs (each time it runs is called a "generation") it will look at the unreachable queue for the last cycle mark the memory for bar as free, remove it from the unreachable queue and compact the heap so it is contiguous. So it has a lot to do. An object is usually cleaned up in 2 to 3 generations.

If you mark the reference var as null, th garbage collector can more qucikly see that nothing is referencing that object. But it only makes a minor difference in GC run time if everywhere you set all reference vars to null. If you leave some with a reference, its a waste of time.

If you call dispose() you save the GC time for that one object because it doesnt have to look all over. It will immediately put the reference to it in "unreachable" because its been disposed. And you save the GC a generation for that object.

Too much information? Actually this is simplified.

The "no" part  comes in because you scan help GC a tiny bit more by calling dispose() AND set the var to null. Why? Even tho the memory is on the unreachable queue, GC has to check other allocated memory to see if any references point to it, as in the first generation I mentioned above. If there is a null in it it knows it doesnt have to look there. BUT that is really minor. Dispose() by itself helps more adding the null, again, you will never notice.

Also more to "no" part: Only part of the framework objects implment Dispose. Most places I've worked dont bother calling
Dispose() or setting vars to null. Its considered good practice, but even with both you will not notice a difference in most apps. BUT if you have lots of web hits for web apps, or lots (millions) of database access or lots (millions) of memory use in winForms, then you notice it. Then you should do it. You can also implemenht the IDispose() interface yourself on your own objects.

So, setting the ref var to null, does very, very close to nothing.

oh sorry angelIII and nsanga, I got kinda verbose. While I was writing that tome, you guys posted, I wasnt trying to steal anyones answer. Man, I gotta keep my answers shorter.

Just a minor tidbit calling close or dispose on a SQLConnection is not just recommended on ASP.Net it's a requirement if you get any significant traffic. If you simply set it to null or let it go out of scope the connection will remain in the connection pool for hours. Depending on the site of your pool a meager 10 visitors just visiting a few pages can easily take down your site and a single user could if they wanted to by simply clicking refresh several dozen times.

Need to clarify a couple of wrong things here:

1) Calling Dispose() does not make GC run sooner.  It simply (if used properly) clenas up any _unmanaged_ resources that normally would not get cleaned up until GC runs.  Which is why Cyrex is correct is saying that calling Dispose is more or less required on data connections to improved scalability.
2) Setting an object to null if it is the last reference actually does nothing for improving collection.  The GC is actually smart enough to know that no more references to that object are made and so can collect the object after the last reference to the object is used (potentially before the reference is set to NULL).

Bottom Line:
Any object that implements IDisposable should be disposed of as soon as the object is no longer needed.  A clean way to do this is to create disposable objects with a using block:

using(SqlConnection conn = new SqlConnection(connString))
{
  ...
}

this will ensure that the object is disposed at the end of the block even if an exception is thrown.

1.I didnt not say it makes "GC run sooner". It will reduce the amount of work GC has to do meaning the GC can complete its running state in less time. It doesnt run sooner.

2. Setting the reference to null is really pretty useless as I said. But the GC is only smart enough to know when the object is not used because it has to build a graph of all the objects that are reachable from the root references. It does this by by first adding all the objects that are referenced by the root refeence, then recursively adding objects that are referenced by any added object. I did not say that setting the last reference to null does anything to improve collection. By definition, if it is the last reference, the GC would be done with that graph path at that point regardless.  Otherwise, That would be like continuing to look for something after you found it.

Improvements in the amount of CPU time used by GC will be in microseconds, which is why this is all academic unless you have millions of managed resources.