Develop Reference

Destructor in C# basic program does not work (output missing)

I have written the very basic program below, I am new to C#. The destructor ~Program() doesn't get called, so I do not see in the output the 'Destructor called' string. I have checked other similar questions but I don't find the answer to mine. Thanks.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using static System.Console;
namespace LyfeCicleObject
{
class Program
{
public Program()
{
WriteLine("Cons called");
}
~Program()
{
WriteLine("Destructor called");
}
static void Main(string[] args)
{
WriteLine("Main started");
Program p1 = new Program();
{
WriteLine("Block started");
Program p2 = new Program();
WriteLine("Block ended");
}
WriteLine("Main ended");
}
}
}

The short answer -- the reason you're not seeing the "Destructor called" output -- was buried somewhere in the comments:
.NET Core does not run finalizers at the end of the program
(See: Finalizers (C# Programming Guide)).
.NET Framework will attempt to do it but .NET Core just won't do it.
Disclaimer: We have no way of knowing if these statements will continue to hold true; this is how they're implemented and documented as of now.
According to Raymond Chen, though, in his post Everybody thinks about garbage collection the wrong way, it would not be invalid if .NET Framework didn't run finalizers at the end of the program, either. The relevant quote, which says it from a different perspective, is this:
A correctly-written program cannot assume that finalizers will ever run.
So as long as you don't assume that finalizers will run, it shouldn't matter how they're implemented or if an implementation changes.
Before going any further with C#, you're going to have to abandon the idea of destructors in .NET because they simply don't exist. C# uses C++'s destructor syntax for finalizers but the similarities stop there.
The good news is that there is a way to do something close to what you were trying to do, but it takes a paradigm shift, a substantial change in how you think about resource acquisition and release. Whether or not you really need to do it is a totally different question.
Finalizers aren't the only way, or even the best way, to release resources that need to be released in a timely manner. We have the disposable pattern to help with that.
The disposable pattern allows class implementors to opt in to a common mechanism for deterministically releasing resources (not including memory on the managed heap). It includes finalizers but only as a last chance at cleanup if the object wasn't disposed properly, especially if the process isn't terminating.
I'd say the main differences you'll see compared to C++ destructors are:
There's more that the class's implementor must do support the disposable pattern.
The class's consumer also has to opt in to it with a using statement.
What you won't see is that the memory won't necessarily be reclaimed immediately.
If you want to know more about how, read on...
Before I get into any code, it's worth mentioning some points of caution:
A finalizer should never be empty. It causes instances to be kept alive longer and for nothing.
As mjwills stated in a comment, 99.9% of the time, you shouldn't be writing a finalizer. If you find yourself writing one, take a step back and make sure you have a good reason to do it in terms of .NET code and not because you would do it that way in C++.
More often than not, you'll be overriding Dispose(bool) after deriving from a class that implements the disposable pattern rather than creating the base of a class hierarchy that needs to be disposable. For example, the .Designer.cs files in Windows Forms applications override Dispose(bool) in order to dispose of the components field if it's not null.
Okay, code...
The following is an example of a simple class that implements the disposable pattern. It doesn't provide support for child classes so it's marked sealed and Dispose(bool) is private.
public sealed class SimpleDisposable : IDisposable
{
public SimpleDisposable()
{
// acquire resources
}
~SimpleDisposable()
{
Dispose(false);
}
public void Dispose()
{
// Suppress calling the finalizer because resources will have been released by then.
GC.SuppressFinalize(this);
Dispose(true);
}
private void Dispose(bool disposing)
{
if (disposing)
{
// release managed resources
// (you don't want to do this when calling from the finalizer because the GC may have already finalized and collected them)
}
// release unmanaged resources
}
}
Actual cleanup takes place in the Dispose(bool) method. If the parameter is true, it means that disposal is happening via the IDisposable interface (usually a using statement but not necessarily) and it's okay to clean up managed resources as well. If it's false, it means that disposal is happening as part of a GC sweep, so you can't touch managed resources because they may have already been collected.
If you're writing a base class that needs to support the disposable pattern, things change slightly: Dispose(bool) is becomes protected and virtual so it can be overridden by subclasses but is still inaccessible to the consumer.
The following is an example of a base class that supports the disposable pattern for subclasses.
public abstract class BaseDisposable : IDisposable
{
protected BaseDisposable()
{
// acquire resources
}
~BaseDisposable()
{
Dispose(false);
}
public void Dispose()
{
GC.SuppressFinalize(this);
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// release managed resources
}
// release unmanaged resoures
}
}
And then the following is a subclass that uses that support. Subclasses don't also need to implement the finalizer or IDisposable.Dispose. All they have to do is override Dispose(bool), dispose of their own resources, and then call the base implementation.
public class DerivedDisposable : BaseDisposable
{
public DerivedDisposable()
{
// acquire resources for DerivedDisposable
}
protected override void Dispose(bool disposing)
{
if (disposing)
{
// release DerivedDisposable's managed resources
}
// release DerivedDisposable's unmanaged resources
// Let the base class do its thing
base.Dispose(disposing);
}
}
So what does it mean to dispose managed and unmanaged resources?
Managed resources are things like other disposable objects and even non-disposable objects (e.g. strings). Some disposable types in the BCL will set such fields to null to ensure that the GC doesn't find active references to them.
When your class is being disposed, the consumer has decided that it and its resources are no longer needed. If your object contains other disposables, it's okay to dispose those objects, and so on down the chain, because it's not happening during garbage collection.
Unmanaged resources are things like file handles, global memory, kernel objects... pretty much anything you allocated by making a call to the operating system. Those aren't affected by the garbage collector and need to be released no matter what, so they're not subject to the disposing test.
If your disposable object used another disposable object that has an unmanaged resource, it's that object's responsibility to implement the Disposable pattern to release its resources, and your responsibility to use it.
Not all objects that implement IDisposable actually have unmanaged resources. Often a base class will support the disposable pattern simply because its author knows that at least one class that derives from it might need to use unmanaged resources. However, if a class doesn't implement the disposable pattern, one of its subclasses can introduce that support if it needs it.
Let's alter your program a bit and make it do what you were expecting, but using the disposable pattern now.
Note: As far as I know, it's not very common to have Main create an instance of the containing Program class. I'm doing it here to keep things as close to the original as possible.
using System;
internal sealed class Program : IDisposable
{
private readonly string _instanceName;
public Program(string instanceName)
{
_instanceName = instanceName;
Console.WriteLine($"Initializing the '{_instanceName}' instance");
}
~Program()
{
Dispose(false);
}
public void Dispose()
{
GC.SuppressFinalize(this);
Dispose(true);
}
private void Dispose(bool disposing)
{
if (disposing)
{
Console.WriteLine($"Releasing the '{_instanceName}' instance's managed resources");
}
Console.WriteLine($"Releasing the '{_instanceName}' instance's unmanaged resources");
}
private static void Main(string[] args)
{
Console.WriteLine("Main started");
Program p0 = new Program(nameof(p0));
using (Program p1 = new Program(nameof(p1)))
{
Console.WriteLine("Outer using block started");
using (Program p2 = new Program(nameof(p2)))
{
Console.WriteLine("Inner using block started");
Console.WriteLine("Inner using block ended");
}
Console.WriteLine("Outer using block ended");
}
Console.WriteLine("Main ended");
}
}
Build and run against .NET Framework 4.7.2 and you get the following output:
Main started
Initializing the 'p0' instance
Initializing the 'p1' instance
Outer using block started
Initializing the 'p2' instance
Inner using block started
Inner using block ended
Releasing the 'p2' instance's managed resources
Releasing the 'p2' instance's unmanaged resources
Outer using block ended
Releasing the 'p1' instance's managed resources
Releasing the 'p1' instance's unmanaged resources
Main ended
Releasing the 'p0' instance's unmanaged resources
Build and run against .NET Core 2.1 and you get the following output:
Main started
Initializing the 'p0' instance
Initializing the 'p1' instance
Outer using block started
Initializing the 'p2' instance
Inner using block started
Inner using block ended
Releasing the 'p2' instance's managed resources
Releasing the 'p2' instance's unmanaged resources
Outer using block ended
Releasing the 'p1' instance's managed resources
Releasing the 'p1' instance's unmanaged resources
Main ended
Instances p1 and p2 were disposed in the reverse order in which they were constructed because of the using statements, and both managed and unmanaged resources were released. This was the desired behavior behind trying to use a "destructor".
On the other hand, .NET Framework and .NET Core did things a bit different at the end, showing the differences I mentioned at the beginning:
.NET Framework's GC called the finalizer for p0 so it only released the unmanaged resources.
.NET Core's GC did not call the finalizer for p0.

If you want to see the output from finalizer:
add new method
initialize variable p1 inside
add GC.Collect()
call new method from Main
profit
If you want to know the reason of current behavior: the p1 variable exists in the scope of the Main method and will be collected by the GC when scope gets unreachable and I suppose it happens when program already stopped that means no GC (memory will be released in another way).

How to do Sentry pattern in C#?

In C++, I'm used to using the sentry pattern to ensure that resources acquired are properly released when the block or function exits (see here for example). I used this, for example, for grabbing the graphics state, and then I can do whatever I want to that state, and it gets put back when the sentry object (reference) goes out of scope.
Now I'm using C#, and the same trick doesn't work, because the destructor doesn't get called until who-knows-when later.
Is there some OTHER method that is guaranteed to fire when an object's last reference is released? Or do I just have to remember to call some Restore() or Apply() or DoYourThing() method before returning from any method where I would otherwise use a sentry?

C# has finalizers, like C++, that are called when an object is destroyed. They are in the same form as C++, that is:
~ClassName()
{
}
As you know, though, C# does not have deterministic memory management, and so this isn't really a great guarantee. AS a direct result, you should not use finalizers for releasing unmanaged resources in C#. Instead, we use the IDisposable interface. This exposes a single method on the implementor, Dispose, which is intended to be called when you want to release unmanaged resources.
public class MyDisposable : IDisposable
{
public void Dispose()
{
// get rid of some expensive unmanaged resource like a connection
}
}
We can also use the using sugar to allow semantic invocation of Dispose() when the using block terminates (gracefully or not).
using(var disposable = new MyDisposable)
{
// Do something with the disposable
} // Dispose is invoked here
Should you find yourself using finalizers and Dispose, you can consider using the GC.SuppressFinalize method, although that's a bit out of my scope. There was a really good discussion elsewhere on StackOverflow about this here
This can be used to perform RAII-esque trickery, of course, such as
using(var guard = new Guard(resource))
{
}

C# provides the using block for this case, which works on any object that implements IDisposable.
For example, if you have a type class Foo : IDisposable then you can do this:
using (new Foo(/* ... */)) {
// Your code that depends on this resource.
}
This is equivalent to:
Foo x = new Foo(/* ... */);
try {
// Your code
} finally {
if (x != null) {
((IDisposable)x).Dispose();
}
}
Except, of course, that you don't have access to x. You can, however, gain such access if you need it by creating a variable in the using block:
using (Foo foo = new Foo(/* ... */)) {
// Your code that uses "foo"
}
The standard way of creating a class that can be disposed of this way or by the garbage collector is:
class Foo : IDisposable {
protected virtual void Dispose(bool disposing) {
// Your cleanup code goes here.
}
public void Dispose() {
GC.SuppressFinalize(this);
Dispose(true);
}
~Foo() {
Dispose(false);
}
}

To implement deterministic deallocation of unmanaged resources, you would use a Dispose pattern. For many cases you can combine this with a using block if you want this to occur within a specific scope.
File handles or handles to a graphics device would usually be considered a unmanaged resource. These are resources that the .NET framework does not track references for and does not automatically deallocate.
If it is managed resource, just references to C# objects/lists, then usually deterministic deallocation is not necessary, and the garbage collector can usually handle these more efficiently than you can. Don't worry so much about when managed resources are deallocated. If you no longer have a reference to them, then they should be of no concern. The concern comes when you are done with something but somehow have a lingering reference to it that is preventing the GC from deallocating it.

It sounds like what you're describing is objects that implement the IDisposable interface for C#. the IDisposable has a Dispose() method, that when defined properly on your own objects, is used to release resources.
Additionally C# does have destructors defined as such:
public class Foo
{
public Foo()
{
// constructor
}
~Foo() // destructor
}
when wrapping IDisposable objects in a using block, the Dispose() method is automatically called, the other option is to throw it in a finally block (when not using... using)

The easiest way to do this is enclosing the sentry object in a using statement. So something like this.
using (sentry = new Sentry())
{
//do your stuff here
}
After this block, sentry will have been released and out of scope.

Disposable Class

Please consider the following class:
public class Level : IDisposable
{
public Level() { }
public void Dispose() { }
}
My question is, if I call the Dispose method, will the class actually be disposed (garbage collected)?
ex:
Level level = new Level();
level.Dispose();
Thanks.

My question is, if I call the Dispose method, will the class actually be disposed?
If by disposed you mean garbage collected, then no, this won't happen. What will happen when you call the Dispose method is, well, the Dispose method be called and its body executed.
Also it is recommended to wrap disposable resources in a using statement to ensure that the Dispose method will always be called even in the event of an exception. So instead of manually calling it you could:
using (Level level = new Level())
{
// ... do something with the level
}
Normally the Dispose method is used when the object holds pointers to some unmanaged resources and provides a mechanism to deterministically release those resources.

I assume that what you are after is a way to know that Dispose() was called?
You can do that either in the consuming code by setting the instance to null after disposing:
Level level = new Level();
//do stuff with the instance..
level.Dispose();
level = null;
//in other place:
if (level != null)
{
//still available
}
Or in the class itself, add boolean flag and in every method check for it:
public class Level : IDisposable
{
private bool disposing = false;
public Level() { }
public void Foo()
{
if (disposing)
return;
MessageBox.Show("foo");
}
public void Dispose()
{
if (disposing)
return;
disposing = true;
}
}

Each class that implements IDisposable defines what it means to be disposed. By that line of reasoning, yes, your class will be as disposed as it wants to be.

No, the instance won't be garbage collected due to calling Dispose. The Dispose method is where you can release any resources held by the instance, it isn't about disposing the instance itself.

If you call Dispose() it will be disposed, which doesn't absolutely mean that it will be garbage collected,seems to me that is your question, if not please clarify.

In .NET Disposing and garbage collection are two different things:
The point of disposing is to release any resources that are either not managed by .NET (like manually allocated memory) or that have interests in being released as soon es they aren't needed anymore (like file handles or network connections).
The purpose of garbage collection is to free memory that is managed by .NET (like normal objects).
So, as others pointed out: your object will not necessarily be garbage collected when it gets disposed.

When does the Dispose Method get called? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
IDisposable Question
I have written a class and implemented the IDisposable interface.
I implemetned the Dispose method and put a Code Break in the method.
My assumption is it would have been called when the Class went out of scope due to C# Garabage collection.
I want the dispose method to close an unmanaged resource. I thought it would be more elegant than just calling the method LogOff() instead getting it called whenever the method went out of scope?
But it doesn't seem to get called or stop at the code break.

You need to explicitly call Dispose on any objects that implement IDisposable. If you use the using() {} code construct the compiler will automatically call Dispose at the end of the using block.
A good pattern is to also track via a private boolean field whether dispose has been called or not, and if not call it from the objects finalizer (and also call GC.SuppressFinalize() from your Dispose method assuming that you handle all finalization tasks from there also).

You should consider wrapping your interaction with your IDisposable class in a using statement. Doing so will allow you to specify when your object goes out of scope, and ensures the Dispose() method gets called.
For the correct syntax, see the example from the referenced MSDN article:
using System;
class C : IDisposable
{
public void UseLimitedResource()
{
Console.WriteLine("Using limited resource...");
}
void IDisposable.Dispose()
{
Console.WriteLine("Disposing limited resource.");
}
}
class Program
{
static void Main()
{
using (C c = new C())
{
c.UseLimitedResource();
}
Console.WriteLine("Now outside using statement.");
Console.ReadLine();
}
}

Short answer: Dispose() is called when you call it.
Long answer: take a look at using block. This is a syntax sugar that meant to be used together with IDisposable interface for pretty and safely disposing code, and is roughly equivalent to
Foo foo = new Foo();
try
{
// your code that uses foo
}
finally
{
foo.Dispose();
}
In other words foo is guaranteed to be disposed upon leaving using() scope.

Garbage collection does not happen immediately after a variable goes out of scope. The GC runs periodically and .NET has different "levels" of Garbage collection. Different levels get collected more frequently. If you want your object's dispose method to be called immediately, you should use a using statement
using (MyClass object = new MyClass())
{
//ensures Dipose is called, even if exceptions are thrown
}

My assumption is it would have been called when the Class went out of scope due to C# Garabage collection.
That's now how garbage collection works. There's two things going on here:
Garbage collection - this cleans up objects at some time after there's no longer any references left to them. This implies that the objects have gone out of scope (if they are locals), but notably GC doesn't say when this cleanup happens - it usually happens lazily when the system decides it needs to run a collection to free up more memory. The method that is called to clean up resources in this case is the finalizer, which in C# has the form ~Classname().
IDisposable: the problem with GC is that you have no control over when the finalizer is called, so IDisposable was introduced as a pattern to be used when you need resources to be cleaned up at a specific time and don't want to wait for a collect to happen. It's up to the caller code to call Dispose() as appropriate, there's no GC support. C# does have the using(){} syntax, which simplifies this, and calls Dispose() automatically at the end of the using block.

Disposing objects in the Destructor

I have an object that has a disposable object as a member.
public class MyClass
{
private MyDisposableMember member;
public DoSomething
{
using (member = new MyDisposableMember())
{
// Blah...
}
}
}
There can be many methods in MyClass, all requiring a using statement. But what if I did this instead?
public class MyClass
{
private MyDisposableMember member = new MyDisposableMember();
public DoSomething
{
// Do things with member :)
}
~MyClass()
{
member.Dispose();
}
}
As you can see, member is being disposed in the destructor. Would this work? Are there any problems with this approach?

Ideally, Dispose() should have already been called prior to finalization. It would be better to follow the typical dispose pattern, and allow the user to Dispose() the object properly, and have the finalizer Dispose of it if dispose has not already been called.
In this case, since you're encapsulating an IDisposable, you really don't need to implement the finalizer at all, though. (At the the point of finalization, your encapsulated member will get finalized, so there's no need to finalize your object - it just adds overhead.) For details, read this blog article I wrote on encapsulating an IDisposable.

You should probably make MyClass implement IDisposable. Inside the Dispose() method, call member.Dispose();. That way the programmer can have control over when the member gets disposed.

DO NOT DO THAT!
The GC will do that for you (indirectly as the object to dispose or another one will contain a destructor)
MyDisposableMember might even be disposed by the GC even before you dispose it - what happens then might not be what you intended to do.
Even worse: Adding a destructor (or finalizer) to a class costs additional time when disposing of the object (much more time as the object will stay in memory for at least one collection cyclus and maybe even promoted to the next generation).
Therfore, it would be completely useless and even backfire.

In your first example the member is not really part of the object's state since you're instantiating it every time it's used and disposing it right after. Since it's not part of the state don't model it as such just use a local variable when needed.
In more general you should put all disposal logic in Dispose() and implement IDisposable then use you class together with using or try-finally

The only thing I see wrong (and it isn't an error) is the fact that in a using statement you explicitly dispose of the object at that point in time (when your function / method is called). The destructor cannot be called they are invoked automatically. So at this point it may take some time for member to be disposed of. Better to implement the IDisposeable interface for MyClass.

Following the Microsoft pattern is your best bet so the users of your class have full control over when it is disposed.
public class MyClass : IDisposable
{
private MyDisposableMember member = new MyDisposableMember();
public DoSomething
{
// Do things with member :)
}
~MyClass()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing) // Release managed resources
{
member.Dispose();
}
// Release unmanaged resources
}
}

When a finalizer runs, one of the following will be true about almost any IDisposable object to which it holds a reference:
The object will have already had its finalizer run, in which case calling Dispose on the object will be at best useless.
The object will not have had its finalizer run, but its finalizer will be scheduled to run, so calling Dispose on the object will be useless.
The object will still be in use by something other than the object being finalized, so calling Dispose on it would be bad.
There are a few situations where calling Dispose in a finalizer might be useful, but most situations fit the cases listed above, which all have a common feature: the finalizer shouldn't call Dispose.