We Keep Coding

IDisposable - what to Dispose in class without external references?

I have small helper classes. The classes are used internally to make sure that certain types of string always have the appropriate format (mail addresses, phone numbers, ids, urls, keys, colors, ...).
I wanted to put them into using blocks, to be able to recycle variable names:
using(Id id = ids.First())
{
Container container = containers.getById(id);
...
}
foreach(Id id in ids.Skip(1))
{
Container container = containers.getById(id);
...
}
As I did this, Visual Studio asked me to mark these classes as Disposable, which I did, but I am not sure what to do with the method stub. Let's take a "Mail Address" class as an example:
public class MailAddress : IEquatable<MailAddress>, IDisposable
{
const string MAILADDRESSPATTERN = ...
protected string _address;
public MailAddress(string address)
{
if (address == null) throw new ArgumentNullException("address");
if (!Regex.IsMatch(address, MAILADDRESSPATTERN)) throw new ArgumentException("address");
this._address = address.ToLower();
}
bool IEquatable<MailAddress>.Equals(MailAddress other)
...
public override int GetHashCode()
...
...
...
public override string ToString()
...
public void Dispose()
{
throw new NotImplementedException();
}
}
What exactly would the Dispose function have to do in such a class? What do I have to dispose of, and what would the Garbage Collector do automatically?
Up to now, I didn't call Dispose on that class anywhere, and it seemed to work fine. Now, that the class is Disposable, do I have to add calls to Dispose throughout the code?

Don't do this, you are abusing the language and the Disposable interface / pattern.
IDisposable is there for very specific reasons, among which are deterministic release of unmanaged resources or when your class owns disposable references.
It is most certainly not a means to create local scope so you can reuse variable names. If you need to do that simply do:
{
Id id = ids.First())
Container container = containers.getById(id);
...
}

The compiler forces you to implement the IDiposable interface in your Id class, because you use it with using. The sole and only purpose of using is to call IDisposable.Dispose after you leave its block. So you can only use it on IDisposable implementations.
The purpose of the IDisposable is to clean up external resources when the object is not used anymore. That includes closing files, disconneting from databases, returning windows handles and much, much more.
Since you don't seem to have anthing to clean up, you have no need for the usingstatement. In those cases when you have to use using (for example you are using one method for different types of objects where some have external resources), you still have to implement the Dispose method to satisfy the interface, but you can leave it empty.
If your class is disposable, you indeed should dispose it whenever you don't need it anymore, even if Dispose does nothing. If you or someone else adds cleanup code to Dispose later, you should rely on it being executed.

Your Dispose method has no purpose at all since you don't seem to have any unmanaged resources. Dispose is only useful in the case you want to manually dispose those resources.
All managed resources are garbage-collected by the GC, so no need for any action on your side. Removing the IDisposable on your class seems to be the appropriate action. That would require to remove the useless using too, which you can exchange for simple brackets:
{
Id id = ids.First();
Container container = containers.getById(id);
...
}

Not sure why you are using the using keyword. The using keyword guaratees a call to Dispose() when the execution leaves the scope of the using. The object inside the using brackets is therefore required to be an IDisposable. If you don't have any resources you need to clean up, there is no need to wrap your object in a using. Since it is not a great idea to use destructors in .net, the logic you would put in a destructor is often placed in the Dispose() method. This allows controlled resource management when combined with the using keyword.

C# IDisposable pattern and throwing ObjectDisposedException

A question for you all.
In my company, we are developing an application that runs inside Microsoft’s MVC framework.
The controller classes that we are implementing inherit from the MVC base class Controller. Example:
public class MyController: Controller
{
protected bool IsDisposed { get; set; }
… various methods…
}
The discussion we are having in the team centers around the Dispose() pattern. Essentially, this involves implementing the IDisposable interface, preferably according to the Microsoft-endorsed pattern.
See for example this link: http://msdn.microsoft.com/en-us/library/fs2xkftw%28v=vs.110%29.aspx
Interestingly, our controller classes do not own any resources, either managed or managed. As a result, the implementation of Dispose(bool) is greatly simplified:
protected override void Dispose(bool disposing)
{
IsDisposed = true;
base.Dispose(disposing);
}
There is some disagreement about the use (or need) of the IsDisposed property, that is used in the following method:
protected void ThrowIfDisposed()
{
if (IsDisposed) throw new ObjectDisposedException(“MyController”);
}
This method is then called at the beginning of every method that does "real" work. The thinking here is that a disposed object should not be used again, hence it should throw the ObjectDisposedException. The other opinion is that, since Dispose(bool) does “nothing” (other than setting the IsDisposed property and calling Dispose(bool) on the base class), the “disposed” object is not really in a state that is unusable, so there is no reason to throw. Therefore, there is no reason to even implement Dispose(bool).
An argument against this is that MyController should throw when it is disposed and one of its methods is called, so that its behaviour does not change should in future versions managed and/or unmanaged resources be added.
The argument against this last point is that MyController should never add any resources in future versions, but rather it should be derived from should the need to add resources occur in the future. An additional question is: why doesn’t the (library) class Controller implement ThrowIfDisposed() or something similar?
So, summarizing, faction one wants to implement Dispose(bool) and ThrowIfDisposed() as shown above, faction two thinks they are unnecessary and wants to do away with them.
I see merits in both viewpoints, cannot really make up my mind. Opinions?

Interestingly, our controller classes do not own any resources, either managed or managed.
Then you do not need the IDisposable pattern.
This method [ ThrowIfDisposed() ] is then called at the beginning of every method that does “real” work.
The qustion here is: Why?
If you do want to track a usable/abandoned state then just don't call it IsDisposed.
why doesn’t the (library) class Controller implement ThrowIfDisposed() or something similar?
Because it isn't useful.
Go back to the beginning: why did somebody think this was necessary? What is it for?
It seems you can just rip it out.

If an object receives a request after being disposed, the request should not fail for any reason other than ObjectDisposedException--meaning it shouldn't cause a NullReferenceException, yield garbage data, crash the system, or do any other such thing. That does not imply that the request shouldn't succeed--merely that ObjectDisposedException should be the only mode of failure.
As for IsDisposed, I can't really see much use for it in most cases. Code which doesn't know whether an object is disposed generally won't know much else enough about the object's state to know whether it might be unusable for some other reason; consequently, code that doesn't know whether an object is disposed generally shouldn't do anything with it except--in some cases--to Dispose it, and in most of those cases where one would want to call Dispose on an object if it hadn't already been disposed, one should simply call Dispose unconditionally. There could be some value in having a method MayNeedDisposing which would return true for objects with non-trivial Dispose methods until they've been disposed, but such a method could unconditionally return false for objects with null Dispose methods [in cases where a class would e.g. register a callback purely for the purpose of calling Dispose on something, testing MayNeedDisposing beforehand could be a useful optimization].
Finally, with regard to whether a class or interface should implement or inherit IDisposable, the issue is not whether the type itself acquire resources, but rather whether the last surviving reference to something that does acquire resources may be stored in that type. For example, even though the vast majority of IEnumerator<T> implementations don't acquire resources, some do, and in many such cases the only references to such objects will be stored in variables of type IEnumerator<T>, held by code that has no idea whether the objects in question have any resources or not. Note that non-generic IEnumerator doesn't implement IDisposable but some implementations acquire resources. As a consequence, code which calls IEnumerable.GetEnumerator will be required to call Dispose on the returned enumerator if it implements IDisposable. The fact that IEnumerator doesn't inherit IDisposable doesn't absolve code which receives an IEnumerator implementation that also implements IDisposable from the responsibility of calling Dispose--it merely makes it harder for such code to carry out that responsibility.

Faction two is absolutely right. Don't do it.
Implementing IDisposable in the way described and for the reasons given is a violation of at least three good principles.
You ain't gonna need it. http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Do the simplest thing that could possibly work. http://www.xprogramming.com/Practices/PracSimplest.html
Keep it simple stupid. https://en.wikipedia.org/wiki/KISS_principle
It's just wrong on every level. Don't do it.

Is there any benefit to implementing IDisposable on classes which do not have resources?

In C#, if a class, such as a manager class, does not have resources, is there any benefit to having it : IDisposable?
Simple example:
public interface IBoxManager
{
int addBox(Box b);
}
public class BoxManager : IBoxManager
{
public int addBox(Box b)
{
using(dataContext db = new dataContext()){
db.Boxes.add(b);
db.SaveChanges();
}
return b.id;
}
}
Will there be any benefit in memory use when using BoxManager if it also implements IDisposable? public class BoxManager : IBoxManager , IDisposable
For example:
BoxManager bm = new BoxManager();
bm.add(myBox);
bm.dispose();//is there benefit to doing this?

There are only 2 reasons for implementing IDisposable on a type
The type contains native resources which must be freed when the type is no longer used
The type contains fields of type IDisposable
If neither of these are true then don't implement IDisposable
EDIT
Several people have mentioned that IDisposable is a nice way to implement begin / end or bookended operations. While that's not the original intent of IDisposable it does provide for a very nice pattern.
class Operation {
class Helper : IDisposable {
internal Operation Operation;
public void Dispose() {
Operation.EndOperation();
}
}
public IDisposable BeginOperation() {
...
return new Helper() { Operation = this };
}
private void EndOperation() {
...
}
}
Note: Another interesting way to implement this pattern is with lambdas. Instead of giving an IDisposable back to the user and hoping they don't forget to call Dispose have them give you a lambda in which they can execute the operation and you close out the operation
public void BeginOperation(Action action) {
BeginOperationCore();
try {
action();
} finally {
EndOperation();
}
}

There won't be a scrap of difference between the disposable and non-disposable version if you don't explicitly make use of the Dispose() method.

While your code wouldn't benefit from implementing IDisposable, I can't agree with other opinions here that state that IDisposable is only meant to (directly or indirectly) free native resources. IDisposable can be used whenever the object needs to perform clean up task at the end of it's lifetime span. It's extremely useful together with using.
A very popular example: in ASP.NET MVC Html.BeginForm returns an IDisposable. On creation, the object opens the tag, when Dispose is called it closes it. No native resources involved, yet still a good use of IDisposable.

No, there will be no benefit if you don't do something useful like releasing unmanaged resources that your class might hold in the Dispose method.

One major point of confusion, which may not be applicable in your case but arises often, is what exactly constitutes a "resource". From the perspective of an object, an unmanaged resource is something which an outside entity () is "doing"(*) on its behalf, which that outside entity will keep doing--to the detriment of other entitites--until told to stop. For example, if an object opens a file, the machine which hosts the file may grant that object exclusive access, denying everyone else in the universe a chance to use it unless or until it gets notified that the exclusive access isn't needed anymore.
(*) which could be anything, anywhere; possibly not even on the same computer.
(**) or some way in which the the behavior or state of an outside entity is altered
If an outside entity is doing something on behalf of an object which is abandoned and disappears without first letting the entity know its services are no longer required, the outside entity will have no way of knowing that it should stop acting on behalf of the object which no longer exists. IDisposable provides one way of avoiding this problem by providing a standard means of notifying objects when their services are not required. An object whose services are no longer required will generally not need to ask any further favors from any other entities, and will thus be able to request that any entities that had been acting on its behalf should stop doing so.
To allow for the case where an object gets abandoned without IDisposable.Dispose() having been called first, the system allows objects to register a "failsafe" cleanup method called Finalize(). Because for whatever reason, the creators of C# don't like the term Finalize(), the language requires the use of a construct called a "destructor" which does much the same thing. Note that in general, Finalize() will mask rather than solve problems, and can create problems of its own, so it should be used with extreme caution if at all.
A "managed resource" is typically a name given to an object which implements IDisposable and usually, though not always, implements a finalizer.

No, if there are no (managed or unmanaged) resources there is no need for IDisposable either.
Small caveat: some people use IDisposable to clean up eventhandlers or large memory buffers but
you don't seem to use those
it's a questionable pattern anyway.

From my personal experience (confirmed with discussion and other posts here) I would say, that there could be a situations where your object use massive amount of events, or not massive amount but frequent subscriptions and unsubscription from the event which sometimes leads to that the object is not garbage collected. In this case I in Dispose unsubscribe from all events my object subscribed before.
Hope this helps.

IDisposable is also great if you want to benefit the using () {} syntax.
In a WPF project with ViewModels, I wanted to be able to temporarily disable NotifyPropertyChange events from raising. To be sure other developers will re-enable notifications, I wrote a bit of code to be able to write something like:
using (this.PreventNotifyPropertyChanges()) {
// in this block NotifyPropertyChanged won't be called when changing a property value
}
The syntax looks okay and is easily readable. For it to work, there's a bit of code to write. You will need a simple Disposable object and counter.
public class MyViewModel {
private volatile int notifyPropertylocks = 0; // number of locks
protected void NotifyPropertyChanged(string propertyName) {
if (this.notifyPropertylocks == 0) { // check the counter
this.NotifyPropertyChanged(...);
}
}
protected IDisposable PreventNotifyPropertyChanges() {
return new PropertyChangeLock(this);
}
public class PropertyChangeLock : IDisposable {
MyViewModel vm;
// creating this object will increment the lock counter
public PropertyChangeLock(MyViewModel vm) {
this.vm = vm;
this.vm.notifyPropertylocks += 1;
}
// disposing this object will decrement the lock counter
public void Dispose() {
if (this.vm != null) {
this.vm.notifyPropertylocks -= 1;
this.vm = null;
}
}
}
}
There are no resources to dispose here. I wanted a clean code with a kind of try/finally syntax. The using keyword looks better.

is there any benefit to having it : IDisposable?
It doesn't look so in your specific example, however: there is one good reason to implement IDisposable even if you don’t have any IDisposable fields: your descendants might.
This is one of the big architectural problems of IDisposable highlighted in IDisposable: What your mother never told you about resource deallocation. Basically, unless your class is sealed you need to decide whether your descendants are likely to have IDisposable members. And this isn't something you can realistically predict.
So, if your descendants are likely to have IDisposable members, that might be a good reason to implement IDisposable in the base class.

Short answer would be no. However, you can smartly use the nature of the Dispose() executement at the end of the object lifecycle. One have already gave a nice MVC example (Html.BeginForm)
I would like to point out one important aspect of IDisposable and using() {} statement. At the end of the Using statement Dispose() method is automatically called on the using context object (it must have implemented IDisposable interface, of course).

There one more reason that no one mentioned (though it's debateful if it really worth it):
The convension says that if someone uses a class that implement IDisposable, it must call its Dispose method (either explicitly or via the 'using' statement).
But what happens if V1 of a class (in your public API) didn't need IDisposable, but V2 does? Technically it doesn't break backward compatibility to add an interface to a class, but because of that convension, it is! Because old clients of your code won't call its Dispose method and may cause resources to not get freed.
The (almost) only way to avoid it is to implement IDisposable in any case you suspect that you'll need it in the future, to make sure that your clients always call your Dispose method, that some day may be really needed.
The other (and probably better) way is to implemet the lambda pattern mentioned by JaredPar above in the V2 of the API.

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

How do i know when i need to dispose an object?

HOW do i know when i need to dispose of something? Someone just mention i had several objects in my code that i need to dispose of. I had no idea i needed to dispose anything (this is my first week with C#). How do i know when i need to dispose an object? i was using http://msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.aspx and i do not see any mention of dispose on the page or seen it mention in any other objs i was told i to dispose (by someone on SO).
I know i need to when something inherits IDisposable but HOW do i KNOW when it does inherit it?

Similar questions here:
When should I dispose my objects in .NET?
When should I manually dispose of controls? How do I know if a control implements IDisposable?
How to dispose a class in .NET?
Will the GC call IDisposable.Dispose for me?
Identify IDisposable objects

You should dispose anything that implements IDisposable. Just wrap it on an using:
using(var some = new Something())
{
//use normally
}

An easy way would be to type obj.disp and see if intellisense has a dispose method.

The class implements the interface IDisposable, that means that it has a Dispose method.
Not every class that implements IDisposable requires you to call Dispose, but most of them do. If you see that the class implements IDisposable (or has a Dispose method because it inherits the interface from a base class), you have two choises:
Dig deep in the documentation to find out why the class implements IDisposable, and if you really need to call Dispose.
Just call Dispose.
Either method is safe. If the Dispose method doesn't do anything, the call will be very quick. You can even call Dispose more than once without harm.
Even better then just calling the Dispose method is to use a using block:
using (FileStream s = File.OpenRead(path)) {
...
}
At the end bracket of the block the Dispose method is called automatically. The using block is implemented as a try...finally, so the Dispose method is guaranteed to be called even if an exception occurs in the block.

If an class implements IDisposable you should dispose of intances of that class. If it doesn't you don't. In this case HashAlgorithm derives from ICryptoTransform which derives from IDisposable. This means all instance of classes descending from HashAlgorithm must be disposed.

You should dispose of any object that implements the IDisposable interface.
public abstract class HashAlgorithm : ICryptoTransform,
IDisposable
Anything that has unmanaged resources (DB connections for example) should implement the IDisposable interface.
There are a couple of good reasons for this:
You know that the unmanaged resources (which are typically quite scarce) are going to be cleaned up. Usually these will be cleared up in the finalizer anyway, but due to how the GC has to tidy up objects with finalizers this could take a while.
If you implement the standard dispose pattern you save the GC a lot of work as it doesn't need to call the finalizer.

I know i need to when something
inherits IDisposable but HOW do i KNOW
when it does inherit it?
Assuming you're using Visual Studio. I usually right click on the type, then "Go To Definition". If I see that it, or any of its super classes, implement IDisposable, I make sure I call Dispose on it. This is typically done by wrapping it in a using block as others have mentioned.

"Will the last person to leave the room please turn out the lights?"
An object which implements IDisposable holds the information and impetus necessary to do some "clean-up" operations that should happen "sometime", but which can't happen while the object is still in use. If the object is totally abandoned, those clean-up operations won't happen. The system includes a custodian, with which objects can register when they are created; if an object is abandoned by absolutely everyone but the custodian, the custodian can ask the object to perform its cleanup actions before the custodian too abandons it. Note that for a variety of reasons, the custodian isn't 100% effective at handling abandoned objects. It is thus very desirable that, whenever possible, the last entity to hold a useful reference to an object dispose of it before abandoning the reference.