Develop Reference

does the Dispose method inside a function matters?

so lately i've been working with disposable object and i was wondering would it be benific to dispose an object inside a function ?
like between those 2 functions is the use of .Dispose() really matters inside a function since all objects within a function will vanish as soon as it finishes
void FOO()
{
var x= new DisposableObject();
//stuff
}
void FOO()
{
using(var x= new DisposableObject())
{
//stuff
}
}

You should always Dispose() an object that needs it. Even if the object is garbage collected, there could be unmanaged resources that don't get released. Calling Dispose() (or a using as in your second example) ensures that the object can properly release unmanaged resources that it needs to.

All objects within a function will vanish as soon as it finishes
The objects will stay, the local references will vanish. The objects will 'vanish' when garbage collector runs and determines they are unreachable.
Before an unreachable object is removed from memory, it's finalizer will run (if implemented), cleaning all unmanaged resources.
The problem is that all that is not deterministic. You never know when GC will run, in some cases the finalizer will not even be executed.
You should always call Dispose method if it's possible.
If you want more details about finalizers, you should read these 2 articles: part 1, part 2.

Objects do not simply vanish.
The GC collects instances that are not referenced anymore. This may take time as the GC decides when to run and the instance will not be disposed until it does.
If this disposable has unmanaged resources and is implemented correctly the resources will be disposed by the finalizer which is a single thread.
If you're okay with the instance not being disposed for some time and the finalizer isn't busy.. then go ahead. But it's much better if you dispose of it as soon as possible.

Set a breakpoint in the Dispose() method and run these tests with debugging.
TestMethod1 doesn't hit the breakpoint while TestMethod2 does.
As others have noted this is because of the way that GC works in .Net
If you are going to implement the IDiisposeable interface, you probably want to put your class in a using statement or call .Dispose() so you have more predictable application behavior.
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTestProject2
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
var disposable = new DisposableObject();
disposable.DoSomething();
}
[TestMethod]
public void TestMethod2()
{
using (var disposable = new DisposableObject())
{
disposable.DoSomething();
}
}
}
public class DisposableObject : IDisposable
{
public void Dispose()
{
// dispose here
}
public void DoSomething()
{
// do something here
}
}
}

Can we use Dispose method without Implementing IDisposable Interface?

Can we use Dispose method without Implementing IDisposable Interface ?

You can name a method as Dispose and use it as an ordinary method without any restrictions:
public class MyClass {
public void Dispose() {
...
}
}
...
// using() emulation
MyClass m = null;
try {
m = new MyClass();
...
}
finally {
if (m != null)
m.Dispose();
}
but if you want using() syntax you have to implement IDisposable:
public class MyNextClass: IDisposable {
protected virtual void Dispose(Boolean disposing) {
...
}
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
}
...
// compare this with the using() emulation in the code above
using (MyNextClass n = new MyNextClass()) {
...
}
Anyway, even it's possible to name a method Dispose it's not a good practice to surprize (and finally irritate) developers (including you) who read your texts; so either implement IDisposable or find some other name for the method.

Nobody will stop you from doing that but it is very poor design because everybody knows about the idisposable interface. If you give a different meaning to this method, you are obfuscating your design to whoever takes a look at your code later. Maybe even yourself in a few years where you don't remember the reason why you did this .

Managed Objects are disposed automatically even if you do not implement IDisposable, IDisposable let you dispose which runtime won't dispose like files, open handles unmanaged code components.
Implementing a Dispose Method
The pattern for disposing an object, referred to as a dispose pattern,
imposes order on the lifetime of an object. The dispose pattern is
used only for objects that access unmanaged resources, such as file
and pipe handles, registry handles, wait handles, or pointers to
blocks of unmanaged memory. This is because the garbage collector is
very efficient at reclaiming unused managed objects, but it is unable
to reclaim unmanaged objects.
If you do not want to use the IDisposable pattern and want to have your own then I believe that is not recommended way as it one would have to discover that could be obvious using IDisposable.

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.

How to implement IDisposable properly

I've seen so much C# code in my time as a developer that attempt to help the GC along by setting variables to null or calling Dispose() on classes (DataSet for example) within thier own classes Dispose() method that
I've been wondering if there's any need to implement it in a managed environment.
Is this code a waste of time in its design pattern?
class MyClass : IDisposable
{
#region IDisposable Members
public void Dispose()
{
otherVariable = null;
if (dataSet != null)
{
dataSet.Dispose();
}
}
#endregion
}

The GC does not call .Dispose() (It does, however, call the finalize ~MyClass() method, which you can provide a call to the Dispose() method to have resources automatically managed when the GC decides to clean up your class).
You must always provide a way of disposing internal resources such as DataSets to code that uses your classes (and ensure you actually call .Dispose() or wrap the constructor in a using). Using IDisposable on your classes that use internal resources is highly recommended.
From MSDN:
The primary use of this interface is
to release unmanaged resources. The
garbage collector automatically
releases the memory allocated to a
managed object when that object is no
longer used. However, it is not
possible to predict when garbage
collection will occur. Furthermore,
the garbage collector has no knowledge
of unmanaged resources such as window
handles, or open files and streams.
public void Dispose()
{
otherVariable = null;
if (dataSet != null)
{
dataSet.Dispose();
dataSet = null;
}
}

No, Dispose methods are not a waste of time.
The dispose pattern is there to allow a caller to clean up a class as soon as they have finished with it, rather than waiting for the GC to collect it. The delay doesn't matter much for plain heap memory, which is why basic classes like String don't implement it. What Dispose is useful for however is cleaning up unmanaged resources. Somewhere internally, the Dataset class is using an unmanaged resource, so it provides a dispose method to allow you to let it know when that unmanaged resource can be released.
If the pattern has been followed correctly Dataset will also have a finalizer (or some subclass will) which means that if you didn't dispose of it manually, eventually the GC would run, the finalizer would get called and the unmanaged resource would be cleaned up that way. This unmanaged resource might be important though, imagine if it was a file lock, or a database connection, you don't really want to hang around waiting for the GC to run before you can reuse your database connection. Dispose provides a deterministic way of cleaning up resources when they are finished rather than relying on the non-deterministic GC.
As for setting variables to null in a dispose method. It nearly all cases it would be pointless. setting a variable to null removes a reference to that variable, which will make it eligible for garbage collection (if that's the last reference), but as you are disposing of the class anyway, you are likely to be going out of scope for the containing class so the internal class will become eligible for collection anyway.
If you have member variables inside your class that are disposable that you created (not just references you hold), then you should always call dispose on them from your own class's dispose method, but don't bother setting them to null.

Not entirely. If you have member variables which are disposable, then you probably should dispose of it like that. Your object may live longer than the scope of the work it is doing as the garbage collector is not guaranteed to run at any particular time.
Setting managed variables to null is a waste of time though. The object won't get GC'd any faster.

Garbage truck comes to my area every week but it doesn't collect my garbage unless I put my garbage bin in a way that it can collect.
You should simply remove all unwanted event subscriptions, reference and clear unmanaged handlers. Then Garbage Collector will take care of the rest.
Below example show the general best practice to implement IDisposable interface. Reference : https://msdn.microsoft.com/en-us/library/system.idisposable.dispose(v=vs.110).aspx
public class DisposeExample
{
// A base class that implements IDisposable.
// By implementing IDisposable, you are announcing that
// instances of this type allocate scarce resources.
public class MyResource: IDisposable
{
// Pointer to an external unmanaged resource.
private IntPtr handle;
// Other managed resource this class uses.
private Component component = new Component();
// Track whether Dispose has been called.
private bool disposed = false;
// The class constructor.
public MyResource(IntPtr handle)
{
this.handle = handle;
}
// 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);
}
// Dispose(bool disposing) executes in two distinct scenarios.
// If disposing equals true, the method has been called directly
// or indirectly by a user's code. Managed and unmanaged resources
// can be disposed.
// If disposing equals false, the method has been called by the
// runtime from inside the finalizer and you should not reference
// other objects. Only unmanaged resources can be 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;
}
}
// Use interop to call the method necessary
// to clean up the unmanaged resource.
[System.Runtime.InteropServices.DllImport("Kernel32")]
private extern static Boolean CloseHandle(IntPtr handle);
// Use C# destructor syntax for finalization code.
// This destructor will run only if the Dispose method
// does not get called.
// It gives your base class the opportunity to finalize.
// Do not provide destructors in types derived from this class.
~MyResource()
{
// Do not re-create Dispose clean-up code here.
// Calling Dispose(false) is optimal in terms of
// readability and maintainability.
Dispose(false);
}
}
public static void Main()
{
// Insert code here to create
// and use the MyResource object.
}
}

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.