We Keep Coding

CA1063 Modify Dispose() so that it calls Dispose(true), then calls GC.SuppressFinalize on the current object instance and then returns

I have this class:
public abstract class ImplementsIDisposable : IDisposable
{
public abstract void Dispose();
private class InnerClass : ImplementsIDisposable
{
private bool disposedValue;
public override void Dispose()
{
if (!disposedValue)
{
doSomething();
disposedValue = true;
}
GC.SuppressFinalize(this);
}
}
}
And Code Analysis is throwing this message:
CA1063 Modify Dispose() so that it calls Dispose(true), then calls
GC.SuppressFinalize on the current object instance and then returns.
And this one:
CA1063 Ensure that Dispose() is declared as public and sealed.
Both in the this line:
public abstract void Dispose();
Can it be that it wants Dispose() to be implemented in ImplementsIDisposable instead of InnerClass?

There is no reason why public Dispose() should be virtual and much less abstract.
You need to check out the dispose pattern and implement it correctly. The warnings are hinting how you should do it but they can be rather cryptic unless you know how the pattern goes to begin with.
You can read about the Dispose Pattern here, it’s rather simple.
And of course, don’t miss this canonical SO answer on the subject.

I tried to follow the accepted answer, but I kept running into a wall because the last two lines of my method were indeed Dispose(true) and GC.SupressFinalize(this). It turns out that the warning did not make me understand that these should be the ONLY lines in the method, leaving something like the below. I believe the first link in the accepted answer actually does explain this difference, but I didn't read it as carefully as maybe I should have.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
try
{
if (disposing)
{
// call Dispose on all your disposable fields/properties
}
}
finally
{
// free all unmanaged resources here. Note that this is not in an else block.
}
}
Credit to https://netvignettes.wordpress.com/2011/06/29/how-to-implement-dispose-properly/ for getting me on track.

Can you fire a "Disposing" event if Dispose() is called by a Finalizer?

I've noticed there are some classes on MSDN (like this one) that have a Disposing event with the following comment:
Occurs when Dispose is called or when this object is finalized and collected by the garbage collector.
I'd like to implement my own Disposing event in a class of mine. Here's my basic implementation (following the best practices for the dispose pattern):
public abstract class Handle : IDisposable
{
public bool Disposed { get; private set; }
public event System.Action DisposingCompleted;
public Handle()
{
Disposed = false;
}
~Handle()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing = false)
{
if (Disposed)
{
return;
}
if (disposing)
{
HandleManagedResources();
}
HandleUnManagedResources();
Disposed = true;
if (DisposingCompleted != null)
{
DisposingCompleted();
}
}
protected virtual void HandleManagedResources() {}
protected virtual void HandleUnManagedResources() {}
}
Someone mentioned on my Code Review that they're unsure of whether or not firing an event like this is safe because Dispose() might get called from the finalizer but, according to the comments on that MSDN link I've added at the top, it's clear that there are objects firing events when they're Disposed OR Finalized.
Am I missing something or is this safe? How does GraphicsDevice implement an event that's fired from dispose OR when finalized? If the answer is just "No, you can't do this ever" then is there any other way of achieving the same effect? (an event for an object being disposed OR finalized)

If you're going to do anything involving other objects in the Dispose methods you should only do so when Dispose is called explicitly, not when it is called from the finalizer.
The reason for this is that if that other object too is eligible for collection you have no guarantee that that object hasn't already been finalized.

Take on IDisposable pattern

OK, I've read a few things about best practices around IDisposable and I thing I basically get the idea (finally).
My question relates to inheriting from an IDisposable base class. All the examples i see write the same code blocks over and over in the sub-classes and i don't see the advantage.
Why not simply bake a virtual method into the base class, invoke it at the right time from inside the (privately implemented) IDisposable routine so that the sub-classes don't have all that clutter, yet still get a chance do manage their resources?
My proposed base class:
public abstract class DreamDisposableBase : IDisposable
{
private bool _disposed = false;
protected virtual void LocalDispose(bool disposing)
{
}
~DreamDisposableBase()
{
// finalizer being called implies two things:
// 1. our dispose wasn't called (because we suppress it therein)
// 2. we don't need to worry about managed resources; they're also subject to finalization
// so....we need to call dispose with false, meaning dispose but only worry about *unmanaged* resources:
dispose(false);
}
void IDisposable.Dispose()
{
dispose(true); // true argument really just means that we're invoking it explicitly
}
private void dispose(bool disposing)
{
if (!_disposed)
{
// give sub-classes their chance to release their resources synchronously
LocalDispose(disposing);
if (disposing)
{
// true path is our cue to release our private heap variables...
}
// do stuff outside of the conditional path which *always* needs to be done - release unmanaged resources
// tell .net framework we're done, don't bother with our finalizer -
GC.SuppressFinalize(this);
// don't come back through here
_disposed = true;
}
}
}

I wouldn't want every type to have a finalizer. The need to perform any work in a finalizer is very rare. Almost all implementations will not do anything if disposing is true. Finalizers hurt performance because they cause promotion to Gen2, need two collections to be cleaned and calling finalizers is single-threaded.
Most classes do not wrap unmanaged resources, and if they do they should use the SafeHandle types or others. That makes finalizers unnecessary as well.

I do not see any real improvement in your code but as the pattern is non-standard it may be harder for other developers to understand it. To create a derived class using your pattern you need something like this:
class DerivedDreamDisposable : DreamDisposableBase
{
protected override void LocalDispose(bool disposing)
{
if (disposing)
{
// Dispose aggregated objects that are disposable.
}
// Dispose unmanaged resources.
_disposed = true;
base.LocalDispose(disposing);
}
}
Using the standard IDisposable pattern your derived class is something like this:
class DerivedDisposable : DisposableBase
{
bool _disposed;
protected override void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Dispose aggregated objects that are disposable.
}
// Dispose unmanaged resources.
_disposed = true;
}
base.Dispose(disposing);
}
}
By deriving from DreamDisposable you avoid to replicate the field to keep track of the disposed state of the object. However, other than that the methods are effectively the same. Also, in your base class LocalDispose is empty and you have moved the code into the private Dispose method but that can be fixed by doing a small refactoring.
However, many classes will not have any unmanaged resources to release and because calling the Dispose method is idempotent (you can call it several times) you often do not have to keep track of the disposed state and your disposable code is simplified to:
protected override void Dispose(bool disposing)
{
if (disposing)
{
_child1.Dispose();
_child2.Dispose();
}
}
If you do not have any unmanaged resources in your inheritance hierarchy you do not need finalizer and the disposing parameter will always be true. Your Dispose method will then be:
protected override void Dispose(bool disposing)
{
_child1.Dispose();
_child2.Dispose();
}
In general avoiding finalizers are good for performance which is why you call GC.SuppressFinalize to undo the harm you did by implement a finalizer.
But in many situations you still need to keep track of the disposed state of an object because you have to throw ObjectDisposedException if methods are invoked after the object has been disposed, and in that case my simplified Disposed methods is too simple. Here is an example on how to handle that without replicating the _disposed flag in each subclass and still use the standard dispose pattern:
class DisposableBase : IDisposable
{
bool _disposed;
~DisposableBase()
{
Dispose(false);
GC.SuppressFinalize(this);
}
public void Dispose()
{
if (_disposed)
return;
Dispose(true);
_disposed = true;
}
public void DoStuff()
{
ThrowIfDisposed();
// Now, do stuff ...
}
protected virtual void Dispose(bool disposing)
{
// Dispose resources ...
}
protected void ThrowIfDisposed()
{
if (_disposed)
throw new ObjectDisposedException(GetType().FullName);
}
}
Any derived class do not need to keep track of the disposed state and instead should use ThrowIfDisposed in all public methods that depends on the object not being disposed.

You say:
My question relates to inheriting from an IDisposable base class. All
the examples i see write the same code blocks over and over in the
sub-classes and i don't see the advantage.
That is not true, in the IDisposable pattern the method:
protected virtual void Dispose(bool disposing)
should be overrided by inheriting classes.
You need to note that the Dispose(bool disposing) method is actually your
LocalDisposing(bool disposing) method. And this fact, I think, is the source of your confusion.
Please read the related section on the seminal book:
Framework Design Guidelines, Second edition
Quoting the book:
If you are inheriting from a class that already implements the
pattern, simply override the Dispose(bool) method to provide aditional
resource cleanup logic
In derived classes the code looks like:
protected override void Dispose(bool disposing)
{
if(disposing)
{
//release own resources
}
}
Also note that in this case you should call GC.SuppressFinalize(this) only in the non-virtual Dispose method.
Also in your code you are implementing the IDisposable interface implicitly, important to be aware of this.

Is it necessary to use a variable or exactly the property in IDisposable?

When I'm implemeting IDisposable interface, I've work with the bool disposed variable, which is in protected virtual void Dispose(bool disposing).
But I wonder, what if I use not a simple variable, but the property in C# with this situation?
class A : IDisposable
{
bool disposed { get; set; }
...
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
//dispose managed ressources
}
}
disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}

This property:
bool disposed { get; set; }
is almost equivalent to a field. It's effectively this:
bool _disposed;
bool disposed { get { return _disposed; } set { _disposed = value; } }
Given that both the field and the property are private, and you're not adding any behaviour to the property, I'd just stick with a simple field.
Also note that if you can seal your class (so you don't need to worry about subclasses wanting to override Disposing(bool) you can get rid of the Dispose(bool) method entirely, and just implement Dispose() in a simple way.
Indeed, unless you need to keep a flag indicating whether or not the instance has been disposed, you could remove that, too.

It's unclear whether you are talking about a disposed flag or the disposing parameter. If the former, my preferred pattern is to use a private int variable, and have the IDisposable.Dispose implementation Interlocked.Exchange the flag to 1, and call Dispose(bool) if it was previously zero; a read-only protected or public property Disposed should indicate whether the flag is set.
As for the disposing parameter, the Dispose(bool) method should generally only be called with a value of true; the effective purpose of the flag is to change the signature from Dispose(), thus allowing the use of the same name. Inheritable classes should generally only have finalizers if their whole purpose centers around finalization (as with e.g. SafeHandle) so there's no reason to worry about handling Dispose(false).
Note that if one doesn't block double invocations before calling the virtual method, every derived class that wants to be protected will have to define its own redundant flag for that purpose--somewhat wasteful.

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