Use of Finalize/Dispose Method in C#

Finalize vs Dispose

Others have already covered the difference between Dispose and Finalize (btw the Finalize method is still called a destructor in the language specification), so I'll just add a little about the scenarios where the Finalize method comes in handy.

Some types encapsulate disposable resources in a manner where it is easy to use and dispose of them in a single action. The general usage is often like this: open, read or write, close (Dispose). It fits very well with the using construct.

Others are a bit more difficult. WaitEventHandles for instances are not used like this as they are used to signal from one thread to another. The question then becomes who should call Dispose on these? As a safeguard types like these implement a Finalize method, which makes sure resources are disposed when the instance is no longer referenced by the application.

dispose vs finalize how the object free the memory?

You should prevent users of your application from calling an object's Finalize method directly by limiting its scope to protected. In addition, you are strongly discouraged from calling a Finalize method for a class other than your base class directly from your application's code. To properly dispose of unmanaged resources, it is recommended that you implement a public Dispose or Close method that executes the necessary cleanup code for the object. The IDisposable interface provides the Dispose method for resource classes that implement the interface. Because it is public, users of your application can call the Dispose method directly to free memory used by unmanaged resources. When you properly implement a Dispose method, the Finalize method becomes a safeguard to clean up resources in the event that the Dispose method is not called.

// Design pattern for a base class.
public class Base: IDisposable
{
    private bool disposed = false;

    //Implement IDisposable.
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Free other state (managed objects).
            }
            // Free your own state (unmanaged objects).
            // Set large fields to null.
            disposed = true;
        }
    }

    // Use C# destructor syntax for finalization code.
    ~Base()
    {
        // Simply call Dispose(false).
        Dispose (false);
    }
}

// Design pattern for a derived class.
public class Derived: Base
{
    private bool disposed = false;

    protected override void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Release managed resources.
            }
            // Release unmanaged resources.
            // Set large fields to null.
           // Call Dispose on your base class.
            disposed = true;
        }
        base.Dispose(disposing);
    }
    // The derived class does not have a Finalize method
    // or a Dispose method without parameters because it inherits
    // them from the base class.
}

Source: MSND

Difference between destructor, dispose and finalize method

Destructor implicitly calls the Finalize method, they are technically the same. Dispose is available with objects that implement the IDisposable interface.

You may see : Destructors C# - MSDN

The destructor implicitly calls Finalize on the base class of the
object.

Example from the same link:

class Car
{
    ~Car()  // destructor
    {
        // cleanup statements...
    }
}

The Destructor's code is implicitly translated to the following code:

protected override void Finalize()
{
    try
    {
        // Cleanup statements...
    }
    finally
    {
        base.Finalize();
    }
}

Your understanding for the Destructor is right:

From MSDN

The programmer has no control over when the destructor is called
because this is determined by the garbage collector. The garbage
collector checks for objects that are no longer being used by the
application. If it considers an object eligible for destruction, it
calls the destructor (if any) and reclaims the memory used to store
the object. Destructors are also called when the program exits. It is
possible to force garbage collection by calling Collect, but most of
the time, this should be avoided because it may create performance
issues.

Use of Finalize/Dispose method in C#

The recommended IDisposable pattern is here. When programming a class that uses IDisposable, generally you should use two patterns:

When implementing a sealed class that doesn't use unmanaged resources, you simply implement a Dispose method as with normal interface implementations:

public sealed class A : IDisposable
{
    public void Dispose()
    {
        // get rid of managed resources, call Dispose on member variables...
    }
}

When implementing an unsealed class, do it like this:

public class B : IDisposable
{    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }   
        // get rid of unmanaged resources
    }

    // only if you use unmanaged resources directly in B
    //~B()
    //{
    //    Dispose(false);
    //}
}

Notice that I haven't declared a finalizer in B; you should only implement a finalizer if you have actual unmanaged resources to dispose. The CLR deals with finalizable objects differently to non-finalizable objects, even if SuppressFinalize is called.

So, you shouldn't declare a finalizer unless you have to, but you give inheritors of your class a hook to call your Dispose and implement a finalizer themselves if they use unmanaged resources directly:

public class C : B
{
    private IntPtr m_Handle;

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }
        ReleaseHandle(m_Handle);

        base.Dispose(disposing);
    }

    ~C() {
        Dispose(false);
    }
}

If you're not using unmanaged resources directly (SafeHandle and friends doesn't count, as they declare their own finalizers), then don't implement a finalizer, as the GC deals with finalizable classes differently, even if you later suppress the finalizer. Also note that, even though B doesn't have a finalizer, it still calls SuppressFinalize to correctly deal with any subclasses that do implement a finalizer.

When a class implements the IDisposable interface, it means that somewhere there are some unmanaged resources that should be got rid of when you've finished using the class. The actual resources are encapsulated within the classes; you don't need to explicitly delete them. Simply calling Dispose() or wrapping the class in a using(...) {} will make sure any unmanaged resources are got rid of as necessary.

How to properly use the dispose method on a class

You do not have control over when the Dispose method is called by the garbage collector. If you want to dispose resources when the form is closed, you should manually call the Dispose method when the form is closed.

This is achieved by listening to the FormClosed event of the form.

So you would do something similar to this:

Create this method:

private void Form1_FormClosed(Object sender, FormClosedEventArgs e)
{
    if(this.database != null)
        this.database.Dispose(); 
}

Put this line in your form's constructor:
```
this.FormClosed += Form1_FormClosed;
```

Since you're implementing IDisposable, another solution would be to wrap your database object instantiation in a using statement - this would automatically call Dispose once the code in the using statement completes.

Syntax for your use case is as follows:

using(database db = new database())
{
    //use your db object
} //db is disposed here

What's the purpose of GC.SuppressFinalize(this) in Dispose() method?

When implementing the dispose pattern you might also add a finalizer to your class that calls Dispose(). This is to make sure that Dispose() always gets called, even if a client forgets to call it.

To prevent the dispose method from running twice (in case the object already has been disposed) you add GC.SuppressFinalize(this);. The documentation provides a sample:

class MyResource : IDisposable
{
    [...]

    // This destructor will run only if the Dispose method 
    // does not get called.
    ~MyResource()      
    {
        // Do not re-create Dispose clean-up code here.
        // Calling Dispose(false) is optimal in terms of
        // readability and maintainability.
        Dispose(false);
    }

    // Implement IDisposable.
    // Do not make this method virtual.
    // A derived class should not be able to override this method.
    public void Dispose()
    {
        Dispose(true);
        // This object will be cleaned up by the Dispose method.
        // Therefore, you should call GC.SupressFinalize to
        // take this object off the finalization queue 
        // and prevent finalization code for this object
        // from executing a second time.
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing)
    {
        // Check to see if Dispose has already been called.
        if(!this.disposed)
        {
            // If disposing equals true, dispose all managed 
            // and unmanaged resources.
            if(disposing)
            {
                // Dispose managed resources.
                component.Dispose();
            }

            // Call the appropriate methods to clean up 
            // unmanaged resources here.
            resource.Cleanup()          
        }
        disposed = true;         
    }
}

What is the point of Finalize and Dispose methods in .NET? (see details before answering)

The author of that blog post is a bit confused...

In C#, there is no such thing as a "destructor". Only Finalizers and IDisposable.

The ~ClassName() method is not called a "destructor". It is called a finalizer.

Dispose exists to release resources from code, where the finalizer exists to be called from the GC. Very often, the finalizer calls the Dispose() method, but the "Dispose Pattern" sets you up to only handle unmanaged resources from the finalizer.

You see, when the finalizer gets called, you are on a different thread, and any managed object you have is not necessarily valid. Because of this, if you call Dispose() from the finalizer, you should really be calling Dispose(false) which tells the "Dispose Pattern" to only dispose unmanaged resources.

Further, the "Dispose Pattern" suggests that when Dispose(true) is called, you should suppress the finalizer on that object.

How to Properly Handle Class Variables with Dispose/Finalize Methods

That was also a confusion for me but when I read more about memory management and GC mechanism in .Net everything became clear.

You should call disposeMe.Dispose() only if "disposing=true". Because it is a managed class/resource. I assume that it also implements this dispose and destructor pattern correctly.

Why you should not try to use any managed object outside of the if(disposing) block?

Because GC may not and does not collect your objects by following a graph from owner to owned. So, when the Dispose method is called by Destructor, disposeMe object may already be collected and unreachable. So you can not/should not dispose it in this area.

But you can free unmanaged resources, like unmanaged memory spaces you allocate, handles you opened... Since GC does not know anything about them, it can not collect and free them unless you intentionally free them. If you don't, there will be memory and handle leaks, which will eventually crash the application.

What is the difference between the resources disposed in a finalizer to those released in dispose

The only reason you would use it (and its extremely controversial).

A finalizer allows the clearing an object before it will be deleted by a garbage collector. (That's to say, The GC is responsible for calling it, and clearing the object from memory) If the developer forgot to call Dispose() method of an object, then it will be possible to free the unmanaged resources and thus, avoid the leak.

There are many reasons not to, and many ways to get it wrong. In short there is seldom a reason why you need to do this, or want to do it