The destructor should only release unmanaged resources that your object holds on to, and it should not reference other objects. If you have only managed references you do not need to (and should not) implement a destructor. You want this only for handling unmanaged resources. Because there is some cost to having a destructor, you ought to implement this only on methods that consume valuable, unmanaged resources.
The article doesn’t go into this in more depth, but what sorts of costs are involved with using a destructor in C#?
Note: I know about the GC and the fact the destructor isn’t called at reliable times, that all aside, is there anything else?
Any object that has a finalizer (I prefer that term over destructor, to emphasize the difference from C++ destructors) is added to the finalizer queue. This is a list of references to objects that has a finalizer that has to be called before they are removed.
When the object is up for garbage collection, the GC will find that it’s in the finalizer queue and move the reference to the freachable (f-reachable) queue. This is the list that the finalizer background thread goes through to call the finalizer method of each object in turn.
Once the finalizer of the object has been called, the object is no longer in the finalizer queue so it’s just a regular managed object that the GC can remove.
This all means that if an object has a finalizer, it will survive at least one garbage collection before it can be removed. This usually means that the object will be moved to the next heap generation, which involves actually moving the data in memory from one heap to another.