We Keep Coding

C# implementing IDisposable with GCHandle-Member

What is the correct way to implement the IDisposable-Pattern, given that the implementing class contains a GCHandle-Member?
I came up with this, but it causes my application to leak memory:
public class foo : IDisposable
{
private bool disposed = false;
private readonly byte[] bytes;
private readonly GCHandle hBytes;
private readonly IDisposable someWrapperForUnmanagedData;
public foo(byte[] bytes)
{
this.bytes = bytes;
hBytes = GCHandle.Alloc(bytes, GCHandleType.Pinned);
someWrapperForUnmanagedData = new bar(..., bytes, ...);
}
protected virtual void Dispose(bool disposing)
{
if (disposed) return;
if (disposing)
{
hBytes.Free();
}
someWrapperForUnmanagedData.Dispose();
disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SupressFinalize(this);
}
~foo() => Dispose(false);
}
Microsoft-documentation does not mention how GCHandles are supposed to be used with IDisposable, and I can't seem to find anything on the net.
Should the finalizer for foo call hBytes.Free()?
Following the documentation, the finalizer is only supposed to call cleanup-routines for unmanaged resources, which in this case is only someWrapperForUnmanagedData.

You've got your Dispose method backwards.
When your type's finalizer is called, you should release managed resources that you own.
When your type's IDisposable.Dispose() method is called, you should call Dispose on the things you own, and also release managed resources that you own.
The reason for this is straightforward. The happy case is that your type is disposed (someone calls .Dispose() on it). This gives you the opportunity to release unmanaged resources that you own, and you also need to propagate this Dispose() call down to your children so that they can release their unmanaged resources as well.
If someone forgets to call .Dispose() on you, then the GC will probably save your back by calling your finalize method. In this case, you should release any unmanaged resources you own, but you should not call into any of your children. If any of your children have their own finalizers, then:
The GC will call their finalizer separately, so you should not call it as well.
There's no guarantee of the order that types are finalized, so your children might already have been finalized.
Note the use of the term ownership. An unmanaged resource should have exactly one thing which owns it, and that is the thing which is responsible for releasing it.
Note that your someWrapperForUnmanagedData is not an unmanaged type. It's a C# class, which is very much managed. Unmanaged types are things like raw pointers. If someWrapperForUnmanagedData itself owns some other unmanaged type(s), it should implemenet IDisposable and define a finalizer in order to make sure that those are freed.
GCHandle doesn't have its own finalizer, so there's no way for it to be Free()ed by the GC. Therefore it counts as an unmanaged resource here: you'll need to manually call Free() on it.
So:
protected virtual void Dispose(bool disposing)
{
if (disposed) return;
if (disposing)
{
someWrapperForUnmanagedData.Dispose();
}
hBytes.Free();
disposed = true;
}
Note, as this doc makes clear, you should use a SafeHandle (or one of its subclasses) if possible. SafeHandle implements its own finalizer, so you don't have to.
The runtime also knows about SafeHandle, and this lets it avoid some really nasty race conditions where e.g. your type can be finalized at the same time as it is making an unmanaged call, leading to a nasty crash. If you don't understand this race, this means you should definitely be using a SafeHandle.

Using Disposable Pattern to Clean Up IDispose Member Classes

Part of the disposable pattern includes the following method.
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// TODO: dispose managed state (managed objects).
}
// TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
// TODO: set large fields to null.
disposed = true;
}
}
This method has different handling to clean up managed and unmanaged resources. But what if I want to clean up a class member that implements IDisposable?
Normally, I don't know if that member cleans up managed or unmanaged resources. So if I want my Dispose method to clean up a class member that implements IDisposable, would I call Dispose() on that member in the managed or unmanaged sections in the code above?

You should call Dispose in the managed section (i.e., only when disposing is true).
Part of the guidance in Dispose Pattern under Framework Design Guidelines is:
The Boolean parameter disposing indicates whether the method was invoked from the IDisposable.Dispose implementation or from the finalizer. The Dispose(bool) implementation should check the parameter before accessing other reference objects [...]. Such objects should only be accessed when the method is called from the IDisposable.Dispose implementation (when the disposing parameter is equal to true). If the method is invoked from the finalizer (disposing is false), other objects should not be accessed. The reason is that objects are finalized in an unpredictable order and so they, or any of their dependencies, might already have been finalized.
Another useful resource is Implementing a Dispose Method

The standard way of disposing class members that implements IDisposable is like this:
public class Foo : IDisposable
{
// MemoryStream implements IDisposable
private readonly Stream _stream = new MemoryStream();
private bool _disposed;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (_disposed)
{
return;
}
if (disposing)
{
_stream.Dispose();
}
_disposed = true;
}
}
To clarify, cleaning up managed resources means the resource itself implements IDisposable (as MemoryStream does above). MemoryStream/Stream holds the underlying unmanaged resource and its cleanup logic is implemented for you already. There is no need to clean up unmanaged resources in Foo.

Where should a C# COM server call dispose its resources?

I have a COM object implemented in C# (see below). It owns some IDisposable resource. Where should I dispose that resource?
Looks like finalizer is never called and I cannot overload IUnknown::Release method.
[ComVisible(true)]
[Guid("1992EC2F-087A-4264-B5B2-5E2E757F1A75")]
public class ComServer
{
IDisposable disposableResource; //where to dispose IDisposable resource?
public ComServer()
{
disposableResource = File.Open(#"c:\somefile.txt", FileMode.OpenOrCreate);
Console.WriteLine("ComServer.ComServer");
}
~ComServer() //finalizer is never called!
{
disposableResource.Dispose();
Console.WriteLine("ComServer.~ComServer");
}
}
Edited: the COM server is used in a native third party application, it's impossible to call Dispose on client side or make any changes there.

There is no guarantee when of if the finalize will be called. Your ComServer should implement the IDiposable interface itself and release it's disposable members within it.
From MSDN (if you override Object.Finalize)
If you are defining a base class that uses unmanaged resources and
that either has, or is likely to have, subclasses that should be
disposed, you should implement the IDisposable.Dispose method and
provide a second overload of Dispose, as discussed in the next
section.
class BaseClass : IDisposable
{
// Flag: Has Dispose already been called?
bool disposed = false;
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (disposed)
return;
if (disposing) {
// Free any other managed objects here.
//
}
// Free any unmanaged objects here.
//
disposed = true;
}
~BaseClass()
{
Dispose(false);
}
}
Then call Dispose explicitly if you need it disposed or use using where ever possible.
using(ComServer com = new ComServer()) {
// operate on the ComServer
} // Dispose will be called automatically when the leaving the using block

Finalizer will never be called if your object is not marked for garbage collection. Go and look for the reason.
As to Dispose, only you can decide when to dispose your objects. It depends on the architecture, lifecycle of your objects. Generally speaking, you should call Dispose() when the object is no longer needed.
The best thing you can do is to implement IDisposable on your ComServer and invoke Dispose where your objects are no longer needed, or you can just wrap them in using constructions.
Tseng provided an example of standard implementation of IDisposable pattern, though consider that a good program does not need finalizers. Generally, it's a bad practice to leave your objects with intention to rely upon the mechanism of finalizing.
If you want to test your finalizer, than you can create your object, do not dispose it, call GC.Collect(). This call will force the garbage collection and if your object is eligible for garbage collection your finalizer will be invoked. But just remember never to use GC.Collect() as part of your production code.

dispose a list of IDisposables in the finalizer

I have a couple of unmanaged memory structures used to communicate with c++ dlls.
Each such structure has to be freed manually, so I wrap it in a MyUnmanagedStructure which implements IDisposable.
I always need a variable number of these structures together, so I have a collection MyUnmanagedStructureCollection which also implements IDisposable.
(see below for the minimal example code)
As long as the user of my library always calls Dispose() or wraps the collection with using() {} there is no problem, but I cannot assure that. I do not want to leak memory even if the user does not dispose the collection manually.
When the MyUnmanagedStructureCollection.Dispose() method is called by the garbage collection via finalizer instead, then as far as I understand I cannot be sure that my private List<MyUnmanagedStructure> has not been garbage collected already, so how can I dispose of each structure in that case?
In my finalizing code, should I attempt to iterate over the list, hoping that it has not been garbage collected yet?
Is it good practise to do this in a try/catch block, catching ObjectDisposedException?
Or should I let each unmanagedStructure "fend for itself", relying on the individual finalizers, and simply do nothing in the finalizer of my collection?
public class MyUnmanagedStructureCollection : IDisposable
{
private List<MyUnmanagedStructure> structures;
private bool disposed = false;
#region standard IDIsposable pattern
public ~MyUnmanagedStructureCollection()
{
this.Dispose(false);
}
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
// Dispose unmanaged resources
// Should not access managed resources,
// the garbage collection may have claimed them already!
// PROBLEM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// this.structures is a List<MyUnmanagedStructure>; so is a managed resource!!!
foreach (var structure in this.structures)
structure.Dispose(disposing)
this.removeAllMemoryPressure();
if (disposing)
{
// Dispose managed resources.
this.structures.Clear();
this.structures = null;
}
}
disposed = true;
}
}
public class MyUnmanagedBuffer : IDisposable
{
...
}

The way the GC works is:
Find all reachable objects
Enqueue all unreachable objects with a finalizer into the finalization queue
Mark all objects that are reachable from from the finalization queue as reachable
Free the remaining unreachable objects
An object that's referenced from an object whose finalizer is running cannot have been garbage collected yet.
The only thing you need to be careful about is that the order of finalization is undefined. So the elements of the list might have been finalized yet, but not collected. Finalization is guaranteed to be single threaded, so you need locking too.
One generally tries to avoid such finalization chains, since independent finalization is simpler. But if some objects need to be disposed before others, such a construction is unavoidable.
You should also consider critical finalization using SafeHandles.
Reachability
One of the guidelines for finalization is that a Finalize method shouldn't touch other objects. People sometimes incorrectly assume that this is because those other objects have already been collected. Yet, as I have explained, the entire reachable graph from a finalizable object is promoted.
The real reason for the guideline is to avoid touching objects that may have already been finalized. That's because finalization is unordered.
Chris Brumme on finalization

Since you're MyUnmanagedBuffer class is a managed resource from point-of-view of your MyUnmanagedStructureCollection class, I think it should handle it as such. This would mean that the MyUnmanagedStructureCollection.Dispose(bool) method would be as below.
protected virtual void Dispose(bool disposing) {
if (!disposed) {
// Dispose unmanaged resources
// Should not access managed resources,
// the garbage collection may have claimed them already!
if (disposing) {
// Dispose managed resources.
// This means that we try to dispose all items in the structures collection.
if (this.structures != null) {
foreach (var structure in this.structures) {
structure.Dispose(disposing);
this.removeAllMemoryPressure(); // What does this?
}
this.structures.Clear();
this.structures = null;
}
}
}
disposed = true;
}

When should I use GC.SuppressFinalize()?

In .NET, under which circumstances should I use GC.SuppressFinalize()?
What advantage(s) does using this method give me?

SuppressFinalize should only be called by a class that has a finalizer. It's informing the Garbage Collector (GC) that this object was cleaned up fully.
The recommended IDisposable pattern when you have a finalizer is:
public class MyClass : IDisposable
{
private bool disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// called via myClass.Dispose().
// OK to use any private object references
}
// Release unmanaged resources.
// Set large fields to null.
disposed = true;
}
}
public void Dispose() // Implement IDisposable
{
Dispose(true);
GC.SuppressFinalize(this);
}
~MyClass() // the finalizer
{
Dispose(false);
}
}
Normally, the CLR keeps tabs on objects with a finalizer when they are created (making them more expensive to create). SuppressFinalize tells the GC that the object was cleaned up properly and doesn't need to go onto the finalizer queue. It looks like a C++ destructor, but doesn't act anything like one.
The SuppressFinalize optimization is not trivial, as your objects can live a long time waiting on the finalizer queue. Don't be tempted to call SuppressFinalize on other objects mind you. That's a serious defect waiting to happen.
Design guidelines inform us that a finalizer isn't necessary if your object implements IDisposable, but if you have a finalizer you should implement IDisposable to allow deterministic cleanup of your class.
Most of the time you should be able to get away with IDisposable to clean up resources. You should only need a finalizer when your object holds onto unmanaged resources and you need to guarantee those resources are cleaned up.
Note: Sometimes coders will add a finalizer to debug builds of their own IDisposable classes in order to test that code has disposed their IDisposable object properly.
public void Dispose() // Implement IDisposable
{
Dispose(true);
#if DEBUG
GC.SuppressFinalize(this);
#endif
}
#if DEBUG
~MyClass() // the finalizer
{
Dispose(false);
}
#endif

SupressFinalize tells the system that whatever work would have been done in the finalizer has already been done, so the finalizer doesn't need to be called. From the .NET docs:
Objects that implement the IDisposable
interface can call this method from
the IDisposable.Dispose method to
prevent the garbage collector from
calling Object.Finalize on an
object that does not require it.
In general, most any Dispose() method should be able to call GC.SupressFinalize(), because it should clean up everything that would be cleaned up in the finalizer.
SupressFinalize is just something that provides an optimization that allows the system to not bother queuing the object to the finalizer thread. A properly written Dispose()/finalizer should work properly with or without a call to GC.SupressFinalize().

Dispose(true);
GC.SuppressFinalize(this);
If object has finalizer, .net put a reference in finalization queue.
Since we have call Dispose(true), it clear object, so we don't need finalization queue to do this job.
So call GC.SuppressFinalize(this) remove reference in finalization queue.

If a class, or anything derived from it, might hold the last live reference to an object with a finalizer, then either GC.SuppressFinalize(this) or GC.KeepAlive(this) should be called on the object after any operation that might be adversely affected by that finalizer, thus ensuring that the finalizer won't run until after that operation is complete.
The cost of GC.KeepAlive() and GC.SuppressFinalize(this) are essentially the same in any class that doesn't have a finalizer, and classes that do have finalizers should generally call GC.SuppressFinalize(this), so using the latter function as the last step of Dispose() may not always be necessary, but it won't be wrong.

That method must be called on the Dispose method of objects that implements the IDisposable, in this way the GC wouldn't call the finalizer another time if someones calls the Dispose method.
See: GC.SuppressFinalize(Object) Method - Microsoft Docs