We Keep Coding

How do I "free" member variables that implement IDispose? [duplicate]

This question already has answers here:
Proper use of the IDisposable interface
(20 answers)
Closed 3 years ago.
I am using a 3rd party class, Table, that represent a database table.
The class has a Close() method and it implements IDispose.
I find that calling Close() many times on such a table is fine.
Likewise calling Dispose() many times is also fine.
However if I call Dispose() I can not call Close() again or I will get a ObjectDisposedException.
I want to use such a Table as a private member variable in a class.
Samples from the provider of the Table class do not call Dispose() on the table.
However since calling Dispose() followed by Close() causes a crash I take it that Dispose() does a full cleanup?
I therefore conclude that I must call Close() followed by Dispose() once and only once?
What is the best way to achieve this?
Should I let my class implement IDispose and use the Dispose pattern with a bool disposed_ variable that ensures that the cleanup is only done once + a GC.SuppressFinalize in the Dispose method?
I have already implemented this pattern and understand how it works.
However I am baffled on how complex this is. I would think that C# code would be simpler than C++.
Is there another simpler/better way to do this?

Hi Andy a good example is here IDisposable Interface
It contains how to dispose managed and unmanaged resource.
If we replace the Table3rd with a MemoryStream It has Close and Dispose methods. We can do this implementation
Fiddle
using System;
using System.IO;
public class Table3rd : MemoryStream{
};
public class MyTable : IDisposable
{
public Table3rd Data { get; private set; }
public MyTable(){
Data = new Table3rd();
}
private bool disposed;
public void Close()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public void Dispose(bool disposing)
{
if (!disposed)
{
try
{
if (disposing)
{
Data?.Dispose();
disposed = true;
}
}
finally
{
Dispose(disposing);
}
}
}
public void Dispose()
{
Close();
}
}
public class Program
{
public static void Main()
{
var table = new MyTable();
var data = table.Data;
var writer = new StreamWriter(data);
writer.Write("Table data");
writer.Flush();
data.Position = 0;
var reader = new StreamReader(data);
var mensaje = reader.ReadToEnd();
Console.WriteLine(mensaje);
// Too many dispose
table.Close();
table.Dispose();
table.Close();
table.Dispose();
}
}
I hope it will be usefull for you.

Rhino-Mocking ExpectationViolationException

I started to use Rhino-Mocks and Unit-Tests a few days ago so I'm new in this.
I created a disposable class like this:
public class SomeClass : IDisposable
{
private bool _disposed;
public SomeOtherClass ObjB { get; private set; }
public SomeClass(SomeOtherClass b)
{
ObjB = b;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (_disposed)
return;
if (disposing)
{
// set all properties to null
ObjB = null;
// ...
}
_disposed = true;
}
}
and the unit test which should check if the dispose was done correctly:
[TestFixture]
public class SomeClassTests
{
[Test]
public void ShouldDisposeCorrectly()
{
var classB = MockRepository.GenerateStrictMock<SomeOtherClass>()
SomeClass smth;
using (smth = MockRepository.GenerateStrictMock<SomeClass>(classB))
{ }
smth.Expect(p => p.ObjB).Should().BeNull();
}
}
Now when I start the test it throws the following error:
Rhino.Mocks.Exceptions.ExpectationViolationException : SomeClass.Dispose(True); Expected #0, Actual #1.
Can you help me to find the missing step? :-)

What are you actually wanting to test here?
That the compiler produces the correct code when you use a using statement? Seems fairly pointeless.
Or that your class implements IDisposable? You could do that with a simpler test.
Or that your disposal routine correctly disposes of the resources? This test doesn't check that. You could completely empty the Dispose(bool) method and the test you say you want to write would still pass.
Better to check that ObjB is null after the object has been disposed and that any other things which should be done in the dispose method have been. What you want to check is that the behaviour when you dispose your object is what you expect

Implementing IDisposable correctly

In my classes I implement IDisposable as follows:
public class User : IDisposable
{
public int id { get; protected set; }
public string name { get; protected set; }
public string pass { get; protected set; }
public User(int UserID)
{
id = UserID;
}
public User(string Username, string Password)
{
name = Username;
pass = Password;
}
// Other functions go here...
public void Dispose()
{
// Clear all property values that maybe have been set
// when the class was instantiated
id = 0;
name = String.Empty;
pass = String.Empty;
}
}
In VS2012, my Code Analysis says to implement IDisposable correctly, but I'm not sure what I've done wrong here.
The exact text is as follows:
CA1063 Implement IDisposable correctly Provide an overridable implementation of Dispose(bool) on 'User' or mark the type as sealed. A call to Dispose(false) should only clean up native resources. A call to Dispose(true) should clean up both managed and native resources. stman User.cs 10
For reference: CA1063: Implement IDisposable correctly
I've read through this page, but I'm afraid I don't really understand what needs to be done here.
If anyone can explain in more layman's terms what the problem is and/or how IDisposable should be implemented, that will really help!

This would be the correct implementation, although I don't see anything you need to dispose in the code you posted. You only need to implement IDisposable when:
You have unmanaged resources
You're holding on to references of things that are themselves disposable.
Nothing in the code you posted needs to be disposed.
public class User : IDisposable
{
public int id { get; protected set; }
public string name { get; protected set; }
public string pass { get; protected set; }
public User(int userID)
{
id = userID;
}
public User(string Username, string Password)
{
name = Username;
pass = Password;
}
// Other functions go here...
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// free managed resources
}
// free native resources if there are any.
}
}

First of all, you don't need to "clean up" strings and ints - they will be taken care of automatically by the garbage collector. The only thing that needs to be cleaned up in Dispose are unmanaged resources or managed recources that implement IDisposable.
However, assuming this is just a learning exercise, the recommended way to implement IDisposable is to add a "safety catch" to ensure that any resources aren't disposed of twice:
public void Dispose()
{
Dispose(true);
// Use SupressFinalize in case a subclass
// of this type implements a finalizer.
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Clear all property values that maybe have been set
// when the class was instantiated
id = 0;
name = String.Empty;
pass = String.Empty;
}
// Indicate that the instance has been disposed.
_disposed = true;
}
}

The following example shows the general best practice to implement IDisposable interface. Reference
Keep in mind that you need a destructor(finalizer) only if you have unmanaged resources in your class. And if you add a destructor you should suppress Finalization in the Dispose, otherwise it will cause your objects resides in memory longer that it should (Note: Read how Finalization works). Below example elaborate all above.
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.
}
}

IDisposable exists to provide a means for you to clean up unmanaged resources that won't be cleaned up automatically by the Garbage Collector.
All of the resources that you are "cleaning up" are managed resources, and as such your Dispose method is accomplishing nothing. Your class shouldn't implement IDisposable at all. The Garbage Collector will take care of all of those fields just fine on its own.

You need to use the Disposable Pattern like this:
private bool _disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Dispose any managed objects
// ...
}
// Now disposed of any unmanaged objects
// ...
_disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Destructor
~YourClassName()
{
Dispose(false);
}

You have no need to do your User class being IDisposable since the class doesn't acquire any non-managed resources (file, database connection, etc.). Usually, we mark classes as
IDisposable if they have at least one IDisposable field or/and property.
When implementing IDisposable, better put it according Microsoft typical scheme:
public class User: IDisposable {
...
protected virtual void Dispose(Boolean disposing) {
if (disposing) {
// There's no need to set zero empty values to fields
// id = 0;
// name = String.Empty;
// pass = String.Empty;
//TODO: free your true resources here (usually IDisposable fields)
}
}
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
}

Idisposable is implement whenever you want a deterministic (confirmed) garbage collection.
class Users : IDisposable
{
~Users()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
// This method will remove current object from garbage collector's queue
// and stop calling finilize method twice
}
public void Dispose(bool disposer)
{
if (disposer)
{
// dispose the managed objects
}
// dispose the unmanaged objects
}
}
When creating and using the Users class use "using" block to avoid explicitly calling dispose method:
using (Users _user = new Users())
{
// do user related work
}
end of the using block created Users object will be disposed by implicit invoke of dispose method.

I see a lot of examples of the Microsoft Dispose pattern which is really an anti-pattern. As many have pointed out the code in the question does not require IDisposable at all. But if you where going to implement it please don't use the Microsoft pattern. Better answer would be following the suggestions in this article:
https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About
The only other thing that would likely be helpful is suppressing that code analysis warning... https://learn.microsoft.com/en-us/visualstudio/code-quality/in-source-suppression-overview?view=vs-2017

DI: Handling Life of IDisposable Objects

So I'm working on my DI/IoC Container OpenNETCF.IoC and I've got a (reasonable) feature request to add some form of lifecycle management for IDisposable items in the container collections.
My current thinking is that, since I can't query an object to see if it's been disposed, and I can't get an event for when it's been disposed, that I have to create some form of wrapper for objects that a developer wants the framework to manage.
Right now objects can be added with AddNew (for simplicity sake we'll assume there's only one overload and there is no Add):
public TTypeToBuild AddNew<TTypeToBuild>() { ... }
What I'm considering is adding a new method (well group of them, but you get the picture):
public DisposableWrappedObject<IDisposable> AddNewDisposable<TTypeToBuild>()
where TTypeToBuild : class, IDisposable
{
...
}
Where the DisposableWrappedObject looks like this:
public class DisposableWrappedObject<T>
where T : class, IDisposable
{
public bool Disposed { get; private set; }
public T Instance { get; private set; }
internal event EventHandler<GenericEventArgs<IDisposable>> Disposing;
internal DisposableWrappedObject(T disposableObject)
{
if (disposableObject == null) throw new ArgumentNullException();
Instance = disposableObject;
}
~DisposableWrappedObject()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
lock(this)
{
if(Disposed) return;
EventHandler<GenericEventArgs<IDisposable>> handler = Disposing;
if(handler != null)
{
Disposing(this, new GenericEventArgs<IDisposable>(Instance));
}
Instance.Dispose();
Disposed = true;
}
}
}
Now, when an items gets added to the container via AddNewDIsposable, an eventhandler is also added so that when it gets Disposed (via the wrapper) the framework removes it from the underlying collection.
I actually have this implemented and it's passing the unit tests, but I'm looking for opinions on where this might be broken, or how it might be made more "friendly" to the consuming developer.
EDIT 1
Since there was a question on how the Disposing event is used, here's some code (trimmed to what's important):
private object AddNew(Type typeToBuild, string id, bool wrapDisposables)
{
....
object instance = ObjectFactory.CreateObject(typeToBuild, m_root);
if ((wrapDisposables) && (instance is IDisposable))
{
DisposableWrappedObject<IDisposable> dispInstance = new
DisposableWrappedObject<IDisposable>(instance as IDisposable);
dispInstance.Disposing += new
EventHandler<GenericEventArgs<IDisposable>>(DisposableItemHandler);
Add(dispInstance as TItem, id, expectNullId);
instance = dispInstance;
}
....
return instance;
}
private void DisposableItemHandler(object sender, GenericEventArgs<IDisposable> e)
{
var key = m_items.FirstOrDefault(i => i.Value == sender).Key;
if(key == null) return;
m_items.Remove(key);
}

Maybe I'm missing something, but why add new methods to the API? When an object is added to the container, you could as-cast to check if it's IDisposable and handle it appropriately if so.
I'm also wondering if you need the destructor. Presuming the container is IDisposable (like Unity's), you could just implement the Basic Dispose Pattern and save a lot of GC overhead.
Some questions that may be applicable:
How do you reconcile IDisposable and IoC?
Can inversion of control and RAII play together?

How do I implement the dispose pattern in c# when wrapping an Interop COM Object?

My class contains an object from Interop and calls a method on it which causes it to alloc stuff. It also exposes a method to free that stuff, so I expect I should call this in Dispose():
class MyClass : IDisposable
{
private DllName.ComClassName comInstance;
void SomeMethod()
{
comInstance = new DllName.ComClassName();
comInstance.AllocStuff();
}
public void Dispose()
{
comInstance.FreeThatStuff();
}
}
Now, I should expand all that to follow the Dispose pattern. I have no other disposable or unmanaged resources to release, so assuming comInstance is managed (isn't that what Interop does, wraps unmanaged into managed?), I think the pattern disolves to:
public void Dispose()
{
if (comInstance != null)
{
comInstance.FreeStuff();
comInstance = null;
}
}
Which leaks unless I explicitly call Dispose() on instances of MyClass, which would make the Dispose pattern flawed? So does that mean comInstance must be unmanaged, and the pattern disolves to:
public void Dispose()
{
DisposeComInstance();
GC.SuppressFinalize(this);
}
~MyClass()
{
DisposeComInstance();
}
private void DisposeComInstance()
{
if (comInstance != null)
{
comInstance.FreeStuff();
comInstance = null;
}
}
EDIT:
To avoid cluttering my class with the full pattern, could I just seal my class?
How do I know ComClassName (and in general any class) is unmanaged?

Ultimately you want this kind of pattern:
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~MyClass()
{
Dispose(false);
}
private void Dispose(bool disposing)
{
if (disposing)
{
// Dispose of disposable objects here
}
// Other unmanaged cleanup here which will be called by the finalizer
if (comInstance != null)
{
comInstance.FreeStuff();
comInstance = null;
}
// Call base dispose if inheriting from IDisposable class.
base.Dispose(true);
}
For a great article on why, check out Implementing IDisposable and the Dispose pattern properly.

Firstly, I agree with those that suggest having a finalizer as a backup, but try to avoid it ever being called by explicitly calling myClass.Dispose or through 'using'.
e.g.
var myClass = new MyClass()
try
{
//do stuff
}
finally
{
myClass.Dispose();
}
or
using (var myClass = new MyClass())
{
//do stuff
}
Marshall.ReleaseComObject
If you are using lots of COM objects, I also suggest you use Mashall.ReleaseComObject(comObj) to explicitly clean up references to the RCW.
So, the code like this suggested elsewhere:
if (comInstance != null)
{
comInstance.FreeStuff();
comInstance = null;
}
would become:
if (comInstance != null)
{
comInstance.FreeStuff();
int count = Marshall.ReleaseComObject(comInstance);
if (count != 0)
{
Debug.Assert(false, "comInstance count = " + count);
Marshal.FinalReleaseComObject(comInstance);
}
comInstance = null;
}
While checking the return value of ReleaseComObject() is not strictly necessary, I like to check it to make sure things are being incremented/decremented as expected.
The 2-dot rule
If you decide to use this, something to be aware of is that some code may need to be refactored to properly release your COM objects. One in particular is what I call the 2-dot rule. Any line using COM objects that contain 2 dots needs close attention. For example,
var name = myComObject.Address.Name;
In this statement we get a reference to the Address COM object incrementing its RCW reference count, but we don't have an opportunity to call ReleaseComObject. A better way to do it would be to break it down (try..finally omitted for clarity):
var address = myComObject.Address;
var name = address.Name;
MyReleaseComObject(address);
where MyReleaseComObject is a utility method wrapping my count check and FinalReleaseComObject() from above.

It looks like you've almost got it nailed. I would fall back to the pattern where you have a protected virtual Disposing that takes a boolean parameter indicating if managed items should be disposed of. That way somebody coming behind you will continue to implement IDisposable properly.
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
~MyClass()
{
this.Dispose(false);
}
protected virtual void Dispose(bool disposing)
{
// if (disposing)
// {
// // Managed
// }
if (comInstance != null)
{
comInstance.FreeStuff();
comInstance = null;
}
// base.Dispose(disposing) if required
}