Is Dispose() in C# equivalent to free() in C

Question 1

You should dispose of anything that implements IDisposable. Typically, this means wrapping the context in a using statement, i.e.:

using (var myInstanceOfSomeClass = new SomeClassImplementingIDisposable())
{
    // do stuff
}

This is C# shorthand for a try/finally block that calls .Dispose().

As far as its relationship to free(), I don't think they are the same. My C is rusty, but .Dispose() is a more generic implementation that can clean up unmanaged resources such as file handles, database connections, memory allocations, etc. What exactly .Dispose() does for any given class is dependent on the implementation by the developer.

Question 2

No.

dispose() releases the resources associated with the object, but does not delete it. C# manages objects through a garbage collector that is the one with the responsability of deleting the objects that can no longer be used from the code.

Read about the interface IDisposable.

Question 3

No.

Dispose is only available on objects which implement the IDisposable interface. It is not required for most things. It is designed to provide the creator of the class with a way to advertise that this object needs some special attention to clean up resources when the consumer has finished with the object. This could be memory but most often it is some form of connection or special resource (port, file, etc.)

In C free() is only used to release memory that has been previously allocated.

In C# streams the Close method will call Dispose and it is often recommended to enclose stream I/O in a 'using(...)' statement.

Question 4

The purpose of Dispose is not to destroy an object, but rather to let an object inform any outside entity (or entities) that may be doing something on its behalf that it no longer needs to do so. For example, an object that encapsulates a file may ask the OS for a handle granting exclusive access to it. The OS will not allow any entity without the handle access to the file until an entity which has the handle says it's no longer needed. If the object ceased to exist without informing the OS that exclusive access was no longer needed, the OS would (probably needlessly) prevent anyone else from using the file at least until the application was closed.

The .NET Framework allows objects to request notification if they are unexpectedly abandoned, and some objects (including, btw, System.IO.File) will use such notifications to let outside entities know their services will no longer be required. Unfortunately, there's generally no guarantee as to how much time may elapse between when an object is abandoned and when (if ever) it will be notified of that. While having the system figure out eventually that e.g. a file is no longer needed may be better than having the file be held forever, having the file be closed promptly is vastly better.

Note that while one would normally think in terms of "closing" a file rather than "disposing" it, consistently using the IDisposable interface for most kinds of objects which have asked other entities to do something on their behalf allows both VB.NET and C# to provide a using construct e.g.

using var myFile = File.Open(whatever)
{
  myFile.doStuff();
}

which will, on exit, automatically let whatever objects have started doing something on behalf of the guarded object know that they no longer need to do so (VB.NET or C# will call Dispose on the guarded object, which will then know who needs to be notified of what). If it were necessary to Close files, Delete GDI objects, Release mutexes, Shutdown daemon services, etc. it would be hard for the language to know what a using statement should do with its guarded object on exit. Having a single Dispose method that does whichever of those things is appropriate greatly simplifies such constructs.