We Keep Coding

Does GC.SupressFinalizer() prevent GC from collecting the managed resources?

If Finalizer (destructor) is implemented in a class and GC.SupressFinalizer() is called from the overriden Dispose() method will the Garbage Collector still take care of any managed resources the instances of that class might have?
What confuses me is Microsofts documentation on this matter. For example the implemenation of IDisposable pattern in the virtual Dispose method takes care of the managed resources as well as the unmanaged. Why is that being done if the GC is taking care of the managed resources by default?
If I define a class like this:
public class Car
{
string plateNum;
}
and use this type as a filed in a class that also deals with unmanaged resources, according to the Microsofts documentation, the proper way to handle the disposal of the objects would be to call Dispose on the Car as well. For one to do so Car has to implement the IDisposable interface. Car is only dealing with the managed resources, there is no reason for doing so in the Car class, I have no idea what Dispose() would even do there, maybe give null to the plateNum? Also why would anyone want to implement IDisposable on the class that deals with the managed resources only?
Having that in mind, why is there a section in the code in the virtual Dispose() method (in the example in the MS documentation) in which managed resources are disposed?
protected virtual 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.
// If disposing is false,
// only the following code is executed.
CloseHandle(handle);
handle = IntPtr.Zero;
// Note disposing has been done.
disposed = true;
}
}
The only reason that I can think of is that GC.SupressFinalize(Object) is telling to the GC that it doesn't need to take care of anything related to the object argument that is given. But this shouldn't be the case because implementing the finalizer should only mean that the object that implements it should be put on the Finalizer queue only after the object has been dealt with by the GC because the Finalizer method, that is explicitly implemented by the user, should be called.
Also if a finalizer is defined does that change the way the GC collects the managed resources that the instance contains or does it just mean that additional code contained in the finalizer will be executed?

There are many Q+A about this already on SO so I'll give you a very practical answer: You won't ever need to write a finalizer.
Summary: In the rare case that you have an unmanaged resource, use the SafeHandle class to make it a managed resource.
When you inspect the full pattern carefully you can see that without unmanaged resources the destructor (aka the Finalizer, ~MyClass() {}) code path does exactly nothing.
And actually having that Finalizer without SuppressFinalize() is very expensive, it will delay the cleanup of your object to the next GC. Promoting its data to gen 1.
The remaining reason for the full pattern with virtual void Dispose(bool) is inheritance. A resource holding class should almost never need that. So make it sealed and all you need (want) is:
public sealed MyClass : IDisposable
{
private SomeResource _myResource;
public void Dispose()
{
_myResource?.Dispose();
}
}
And when you need inheritance then this is the official pattern.

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.

Enforce a method call on class exit

I have a base class that when any class inherited from will add a GUID to a list in another singleton class. I want to have a method in the base class that will remove the GUID from the list when the inherited class has completed its execution. I was looking at putting a method call in a Dispose method but wasn't sure if this was the right way to go as I want the method call to remove the GUID to happen as soon as possible so I did not want to wait for the .NET GC to begin it's work. Also as I have never implemented Dispose before can I just add the IDisposable interface to my base class and create a Dispose method that includes the GUID removal logic or do you have to explicitly include other logic in a Dispose method?

There is no magic in writing the Dispose method. It is no different from any other method. If you do not call it the system will not do it for you.
EXCEPT:
If you really want to make sure that those precious resources are cleaned up properly, you also need to build some safeguards for the situations when the GC gets to your object even though the Dispose method was not called in a usual way.
The way to do it is to also call it from the object destructor and as you do it there are a few things to watch out. First of all when the Dispose runs from the destructor it happens on a thread different from the main thread of your app. Also you cannot use any of the objects your object references by this time they might'of been collected.

You are mixing things, actually.
The garbage collector will never call Dispose on your class. You should implement IDisposable so that a client can ensure that the cleanup method is always called:
using System;
class BaseClass : IDisposable {
bool _guidremoved = false;
public void RemoveGuid() {
if (!_guidremoved) {
_guidremoved = true;
// your logic here
}
}
public void Dispose() {
RemoveGuid();
}
}
class Derived : BaseClass {
}
static class Program {
static void Main(string[] args) {
using (Derived d = new Derived()) {
// do stuff here...
// call RemoveGuid explicitly, if needed
d.RemoveGuid();
} // when we exit this block, Dispose is called
}
}
In this example, the using block ensures that the RemoveGuid method is called by Dispose() if the line with d.RemoveGuid() is not reached.
The garbage collector would, instead, call the destructor (or better, the Finalize method) on your class when it runs, but that would probably not be the proper place to remove the GUID in your case.
Check Implementing Finalize and Dispose to Clean Up Unmanaged Resources for more details.

IDisposable Question

Say I have the following:
public abstract class ControlLimitBase : IDisposable
{
}
public abstract class UpperAlarmLimit : ControlLimitBase
{
}
public class CdsUpperAlarmLimit : UpperAlarmLimit
{
}
Two Questions:
1.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
2.
How would I handle disposing of objects created in the CdsUpperAlarmLimit class? Should this also derive from IDisposable?

Dispose() is never called automatically - it depends on how the code is actually used.
1.) Dispose() is called when you specifically call Dispose():
myAlarm.Dispose();
2.) Dispose() is called at the end of a using block using an instance of your type.
using(var myAlarm = new CdsUpperAlarmLimit())
{
}
The using block is syntactic sugar for a try/finally block with a call to Dispose() on the object "being used" in the finally block.

No, IDisposable won't be called just automatically. You'd normally call Dispose with a using statement, like this:
using (ControlLimitBase limit = new UpperAlarmLimit())
{
// Code using the limit
}
This is effectively a try/finally block, so Dispose will be called however you leave the block.
CdsUpperAlarmLimit already implements IDisposable indirectly. If you follow the normal pattern for implementing IDisposable in non-sealed classes, you'll override void Dispose(bool disposing) and dispose your composed resources there.
Note that the garbage collector does not call Dispose itself - although it can call a finalizer. You should rarely use a finalizer unless you have a direct handle on unmanaged resources though.
To be honest, I usually find it's worth trying to change the design to avoid needing to keep hold of unmanaged resources in classes - implementing IDisposable properly in the general case is frankly a pain. It's not so bad if your class is sealed (no need for the extra method; just implement the Dispose() method) - but it still means your clients need to be aware of it, so that they can use an appropriate using statement.

IDisposable has one member, Dispose().
This is called when you choose to call it. Most typically that's done for you by the framework with the using block syntactic sugar.

I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
No. Its get called when you use using construct as:
using(var inst = new CdsUpperAlarmLimit())
{
//...
}//<-------- here inst.Dispose() gets called.
But it doesn't get called if you write this:
{
var inst = new CdsUpperAlarmLimit();
//...
}//<-------- here inst.Dispose() does NOT get called.
However, you can write this as well:
var inst = new CdsUpperAlarmLimit();
using( inst )
{
//...
}//<-------- here inst.Dispose() gets called.

The best practice recommend when you implement Dispose() method in non sealed class you should have a virtual method for your derived classes to override.
Read more on Dispose pattern here http://www.codeproject.com/KB/cs/idisposable.aspx

when using an IDisposable object, it's always good to use it this way:
using(var disposable = new DisposableObject())
{
// do you stuff with disposable
}
After the using block has been run, the Dispose method will be called on the IDisposable object. Otherwise you would need to call Dispose manually.

When someone calls .Dispose on it.
No, it already implements it through inheritance.

IDisposable is implemented when you want to indicate that your resource has dependencies that must be explicitly unloaded and cleaned up. As such, IDisposable is never called automatically (like with Garbage Collection).
Generally, to handle IDisposables, you should wrap their usage in a using block
using(var x = new CdsUpperAlarmLimit()) { ... }
this compiles to:
CdsUpperAlarmLimit x = null;
try
{
x = new CdsUpperAlarmLimit();
...
}
finally
{
x.Dispose();
}
So, back to topic, if your type, CdsUpperAlarmLimit, is implementing IDisposable, it's saying to the world: "I have stuff that must be disposed". Common reasons for this would be:
CdsUpperAlarmLimit keeps some OTHER IDisposable resources (like FileStreams, ObjectContexts, Timers, etc.) and when CdsUpperAlarmLimit is done being used, it needs to make sure the FileStreams, ObjectContexts, Timers, etc. also get Dispose called.
CdsUpperAlarmLimit is using unmanaged resources or memory and must clean up when it's done or there will be a memory leak

C# disposable objects

Are there some advices about how I should deal with the IDisposable object sequences?
For example, I have a method that builds a IEnumerable<System.Drawing.Image> sequence and
at some point I would need to dispose that objects manually, because otherwise this might lead to some leaks.
Now, is there a way to bind the Dispose() call to garbage collector actions, because I want these objects disposed right in the moment they are no longer accessible from other code parts?
**Or maybe you could advice me some other approach? **
Generally, this seems to be the same problem as it comes, for example, in unmanaged C++ without shared pointers, where you can have a method:
SomeObject* AllocateAndConstruct();
and then you can't be sure when to dispose it, if you don't use code contracts or don't state something in the comments.
I guess the situation with disposable objects is pretty the same, but I hope there is an appropriate solution for this.

(from the question)
Now, is there a way to bind the
Dispose() call to garbage collector
actions, because I want these objects
disposed right in the moment they are
no longer accessible from other code
parts?
GC doesn't happen immediately when your object goes out of scope / reach; it is non-deterministic. By the time GC sees it, there is no point doing anything else (that isn't already handled by the finalizer), as it is too late.
The trick, then, is to know when you are done with it, and call Dispose() yourself. In many cases using achieves this. For example you could write a class that implements IDisposable and encapsulates a set of Images - and wrap your use of that encapsulating object with using. The Dispose() on the wrapper could Dispose() all the images held.
i.e.
using(var imageWrapper = GetImages()) {
foreach(var image in imageWrapper) {
...
}
// etc
} // assume imageWrapper is something you write, which disposes the child items
however, this is a bit trickier if you are displaying the data on the UI. There is no shortcut there; you will have to track when you are done with each image, or accept non-deterministic finalization.

If you want to determiniscally dispose of the objects in the collection, you should call Dispose on each:
myImages.ToList().ForEach(image => image.Dispose());
If you don't do this, and if your objects become unreachable, the GC will eventually run and release them.
Now, if you don't want to manually code the Dispose calls, you can create a wrapper class that implements IDisposable and use it through a using statement:
using (myImages.AsDisposable()) {
// ... process the images
}
This is the needed "infrastructure":
public class DisposableCollectionWrapper<D> : IDisposable
where D : IDisposable {
private readonly IEnumerable<D> _disposables;
public DisposableCollectionWrapper(IEnumerable<D> disposables) {
_disposables = disposables;
}
public void Dispose() {
if (_disposables == null) return;
foreach (var disposable in _disposables) {
disposable.Dispose();
}
}
}
public static class CollectionExtensions {
public static IDisposable AsDisposable<D>(this IEnumerable<D> self)
where D : IDisposable {
return new DisposableCollectionWrapper<D>(self);
}
}
Also notice that this is not the same as the situation you described with C++. In C++, if you don't delete your object, you have a genuine memory leak. In C#, if you don't dispose of your object, the garbage collector will eventually run and clean it up.

You should design your system in a way that you know when the resources are no longer needed. In the worst case, they'll be eventually disposed when the garbage collector gets to it, but the point of IDisposable is that you can release important resources earlier.
This "earlier" is up to you to define, for example, you can release them when the window that's using them closes, or when your unit of work finishes doing whatever operations on them. But at some point, some object should "own" these resources, and therefore should know when they're no longer needed.

You can use the 'using' block, to make sure, the IDisposable is disposed as soon the block is left. The compiler does encapsulate such blocks into try - finally statements in order to make sure, Dispose is called in any case when leaving the block.
By using a finalizer, one can make the GC call the Dispose method for those objects which where "missed" somehow. However, implementing a finalizer is more expensive and decreases the garbage collection efficiency - and possibly the overall performance of your application. So if any possible, you should try to make sure to dispose your IDisposables on your own; deterministically:
public class Context : IDisposable {
List<IDisposable> m_disposable = new List<IDisposable>();
public void AddDisposable(IDisposable disposable) {
m_disposable.Add(disposable);
}
public void Dispose() {
foreach (IDisposable disp in m_disposable)
disp.Dispose();
}
// the Context class is used that way:
static void Main(string[] args) {
using (Context context = new Context()) {
// create your images here, add each to the context
context.AddDisposable(image);
// add more objects here
} // <- leaving the scope will dispose the context
}
}
By using some clever design, the process of adding objects to the context may can get even more easier. One might give the context to the creation method or publish it via a static singleton. That way, it would be available for child method scopes as well - without having to pass a reference to the contex around. By utilizing that scheme it is even possible, to simulate an artificial destructor functionality like f.e. known from C++.

The neat method would be to create your own generic collection class that implements IDisposable. When this collection class is Disposed() ask for each element if it implements IDisposed, and if so Dispose it.
Example (look elsewhere if you don't know about the IDisposable pattern)
public class MyDisposableList<T> : List<T> : IDisposable
{
private bool disposed = false;
~MyDisposableList()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
}
protected void Dispose(bool disposing)
{
if (!disposed)
{
foreach (T myT in this)
{
IDisposable myDisposableT = myT as IDisposable;
if (myDisposableT != null)
{
myDisposableT.Dispose();
}
myT = null;
}
this.Clear();
this.TrimExcess();
disposed = true;
}
}
...
}
usage:
using (MyDisposableList<System.Drawing.Bitmap> myList = new ...)
{
// add bitmaps to the list (bitmaps are IDisposable)
// use the elements in the list
}
The end of the using statement automatically Disposes myList, and thus all bitMaps in myList
By the way: if you loaded the bitmap from a file and you forgot to Dispose() the bitmap you don't know when you can delete that file.

You can call GC.Collect() if you really was to dispose those objects right away but to my understanding it is up to the GC to decide whether to collect the memory.
This in turn will call the Finalize() method for each object that should be released.
Note that if the collection goes out of scope the GC will eventually collect the memory used by the images.
You can also use the using construct if you use a collection that implements IDisposeable. That will guarantee that the objects will be disposed exactly when the collection goes out of scope (or nearly after the end of the scope).