are destructors necessary in C#?

are destructors necessary in C#? - c#

I have a concern. I'm a first year student of computer science. Normally I'm very inquisitive in class but, not always my teacher has an answer, or not always knows the answer. Are destructors necessary in C#? What I mean is if I have to implement a destructor method as I normally do with constructors, is it a good practice or i can avoid it and the garbage collector will do it for me?

Destructors (or finalizers) are good to have in the language - but you should almost never use them. Basically you should only need them if you have a direct handle on an unmanaged resource, and not only is that incredibly rare, but using SafeHandle as a tiny level of indirection is a better idea anyway (which handles clean-up for you). See Joe Duffy's blog post on the topic for more details.
For what it's worth, I can't remember the last time I wrote a finalizer other than to test some odd behaviour or other.
For the vast majority of the time, life is simpler:
The garbage collector can handle memory resource cleanup
If you use an unmanaged resource (e.g. a file) locally within a method, use a using statement to make sure you release it when you're done with it
If you need a reference to an unmanaged resource (or anything else which implements IDisposable) as an instance variable within your type, your type should itself implement IDisposable. (I try to avoid this where possible. Even when it is necessary, you can make life simpler by making your class sealed, at which point you at least don't need to worry about other subclasses having even more unmanaged state to clean up.)

No destructors are not neccesary in C#. The reason why that's true is that in C# the memory is managed automatically and you haven't to do anything except from creating an object. When the garbage collector verifies that an object is not referred anywhere else in your application, then it reclaims its memory, without having you declared any destructor for this object, like we do on C++ for instance.

Nothing is unnecessary in any language. They serve their purpose.
Destructors will destruct the object and you'll end up with object resurrection.(If you try to access destructed object, you might get an error)
GC will automatically do this for you when the object has no longer any references to it. So there's is no need for you to do this explicitly..
Also, implementing IDisposable should be given preference over destructor.

Related

What are the rules for when dispose() is required?

Although I have been coding for some time, I'm really just barely into what I would call an intermediate level coder. So I understand the principle of dispose(), which is to release memory reserved for variables and/or resources. I have also found sometimes using EF I have to dispose() in order for other operations to work properly. What I don't understand is just exactly what requires a release, when to employ dispose().
For example, we don't dispose variables like string, integer or booleans. But somewhere we cross 'a line' and the variables and/or resources we use need to be disposed. I don't understand where the line is.
Is there a single principle or a few broad principles to apply when knowing when to use dispose()?
I read these SO posts (a specific situation, more about how rather than when ) but I don't feel like I understand the basics of knowing when to use dispose(). One comment I saw asked if memory is released when a variable goes out of scope, and that got my attention because until I saw the response was no, it doesn't get released just because it goes out of scope, I would have thought that it does get released when it goes out of scope. I don't want to be what one person in the 2nd link called a 'clueless developer', although I thought that was a little harsh. Some of us are still learning.
So that's why my question is "What determines when a dispose() is really necessary?"
My question is less one of how and more one of when. Of course comments on how would be useful, but even if the method for invoking dispose() is a Using statement, I still need to know when.
Edit to original question: I know this is a long explanation as the marked as duplicate comment note requests, and it's not a rant, I just don't know how to make sure I get the focus on my precise question. Often times we just trip up over the way we ask something. As I mention at the end of this long text I'll edit all this out after we've gotten focused on my issue, assuming we get there. Based on what I've read, I think it's an important question.
The proposed "answer" post is a great post, but doesn't really answer my question. CodeNotFound's comment below also gives a great link but it doesn't really answer my question either. I've provided comments regarding these posts to try and help refine my precise question:
When should I dispose my objects in .NET?: The first answer starts with a comment that
Disposable objects represent objects holding a valuable resource which the CLR is not intrinsically aware of.
Unfortunately I don't understand what the term "Disposable objects ... the CLR is not intrinsically aware of" includes. That's what I'm asking. How do I know if something falls into the category of what I must dispose? We define things to use in code all the time. When do we cross the line and it becomes an object I need to dispose()? BTW, I noticed the author of that post never marked an answer. I don't know if that means he didn't feel the question was answered or if it was just poor follow up on his part, but hopefully I've refined a little what I hoping to understand. When you look closely at the answers, they're not really addressing the issue of which objects require a developer's action to dispose() of them, or how I might go about knowing how to identify which objects. I just don't know what objects or things I create require that I am responsible for disposing. And I get it that GC and other provisions come into play, but again, that's just the how. What seems clear is that most experienced and professional developers know when something they've created needs to be disposed of. I don't understand how to know that.
Proper use of the IDisposable interface: Clearly a popular answer (1681 upvotes), but the marked answer begins with
The point of Dispose is to free unmanaged resources".
OK, but my question is how do I know by looking at something that it is an unmanaged resource? And I don't understand how the note that follows applies to what needs to be disposed.
If you found it in the .NET framework it's managed. If you went poking around MSDN yourself, it's unmanaged... and you're now responsible for cleaning it up."
I don't understand how to use that type of explanation to categorize what I need to dispose() and what I don't. There's all kinds of stuff in the .net framework; how do I separate out things that require I dispose() of them? What do I look at to tell me I'm responsible for it?
After that, the answer goes on to speak at great length about how to dispose(), but I'm still stuck back at what needs to be disposed. To further complicate the topic for me, that author later says "So now we will...
get rid of unmanaged resources (because we have to), and
get rid of managed resources (because we want to be helpful)
So now I need to consider disposing a whole new set of objects that use memory, and I don't know what those are either. The author of the answer later says
For anyone who likes the style of this answer (explaining the why, so the how becomes obvious)...
I understand the author was suggesting other articles, but the author's suggestion that understanding the "why" makes the "how" obvious isn't really legitimate because what's obvious to one person isn't always obvious to another. And even at that, the author focused more on the why and how, and my question is about when, meaning what needs to be disposed(), as opposed to when I'm done with it. I know when I'm done with things, I just don't know which things I'm responsible for when I'm done with them.
It may be obvious or instinctive to most developers what needs to be disposed(), but it's not obvious to me and I'm sure many others at my stage of experience and I was hoping to get a more focused dialogue on what. Certainly why is useful, but in this case only if the why is attached to a what. For example: You have to dispose a DbContext because the CLR won't dispose it - the because explains why, but in this case, it's the DbContext that is the what that must be disposed.
I was hoping there is a general principle for what must be disposed rather than a long list of specific items which would not be particularly useful for people like me who are looking for simple guidelines.
Again, I get it that memory release is important, and also that a lot of experience and expertise goes into learning why and how, but I'm still left struggling to understand what needs to be disposed. Once I understand what I have to dispose(), then I can begin the struggle to learn how to do it.
So is this still a bad question? I'll edit out all of this explanation later to leave the post more succinct assuming we're able to achieve more focus on what I'm asking.
Final Edit: Although I said above I would edit out what I originally thought to be unnecessary text in the question, I think it better to leave it in. I think the way questions are asked has the potential to help us understand the answer. Even though the answer never changes, if we don't connect the answer to the way we framed the question in our minds, we may not really understand the answer. So if the way this question was framed connects with someone, I encourage you to fully read the post marked as the answer, along with the comments. While the answer in the end was really simple, there's a great deal of history and also context that is important to understand the answer to this question. For clarity's sake, the answer was also edited back and forth over the life of this discussion regarding dispose(). Enjoy...

I understand the principle of dispose(), which is to release memory reserved for variables and/or resources.
You do not understand the purpose of dispose. It is not for releasing memory associated with variables.
What I don't understand is just exactly what requires a release, when to employ dispose().
Dispose anything that implements IDisposable when you are sure that you are done with it.
For example, we don't dispose variables like string, integer or booleans. But somewhere we cross 'a line' and the variables and/or resources we use need to be disposed. I don't understand where the line is.
The line is demarcated for you. When an object implements IDisposable, it should be disposed.
I note that variables are not things that are disposed at all. Objects are disposed. Objects are not variables and variables are not objects. Variables are storage locations for values.
Is there a single principle or a few broad principles to apply when knowing when to use dispose()?
A single principle: dispose when the object is disposable.
I don't feel like I understand the basics of knowing when to use dispose().
Dispose all objects that are disposable.
One comment I saw asked if memory is released when a variable goes out of scope, and that got my attention because until I saw the response was no, it doesn't get released just because it goes out of scope, I would have thought that it does get released when it goes out of scope.
Be careful in your use of language. You are confusing scope and lifetime, and you are confusing variables with the contents of the variables.
First: the scope of a variable is the region of program text in which that variable may be referred to by name. The lifetime of a variable is the period of time during the execution of the program in which the variable is considered to be a root of the garbage collector. Scope is purely a compile-time concept, lifetime is purely a run-time concept.
The connection between scope and lifetime is that a local variable's lifetime is often starting when control enters the scope of the variable, and ending when it leaves. However, various things can change the lifetime of a local, including being closed over, in an iterator block, or in an async method. The jitter optimizer may also shorten or extend the life of a local.
Remember also that a variable is storage, and that it may refer to storage. When the lifetime of a local ends, the storage associated with the local might be reclaimed. But there is no guarantee whatsoever that the storage associated with the thing the local refers to will be reclaimed, at that time or ever.
So that's why my question is "What determines when a dispose() is really necessary?"
Dispose is necessary when the object implements IDisposable. (There are a small number of objects that are disposable that need not be disposed. Tasks, for instance. But as a general rule, if it is disposable, dispose it.)
My question is less one of how and more one of when.
Only dispose a thing when you are done with it. Not before, and not later.
When should I dispose my objects in .NET?
Dispose objects when they implement IDisposable, and you are done using them.
How do I know if something falls into the category of what I must dispose?
When it is implementing IDisposable.
I just don't know what objects or things I create require that I am responsible for disposing.
The disposable ones.
most experienced and professional developers know when something they've created needs to be disposed of. I don't understand how to know that.
They check to see if the object is disposable. If it is , they dispose it.
The point of Dispose is to free unmanaged resources". OK, but my question is how do I know by looking at something that it is an unmanaged resource?
It implements IDisposable.
I don't understand how to use that type of explanation to categorize what I need to dispose() and what I don't. There's all kinds of stuff in the .net framework; how do I separate out things that require I dispose() of them? What do I look at to tell me I'm responsible for it?
Check to see if it is IDisposable.
After that, the answer goes on to speak at great length about how to dispose(), but I'm still stuck back at what needs to be disposed.
Anything that implements IDisposable needs to be disposed.
my question is about when, meaning what needs to be disposed(), as opposed to when I'm done with it. I know when I'm done with things, I just don't know which things I'm responsible for when I'm done with them.
The things that implement IDisposable.
I was hoping there is a general principle for what must be disposed rather than a long list of specific items which would not be particularly useful for people like me who are looking for simple guidelines.
The simple guideline is that you should dispose disposable things.
Again, I get it that memory release is important, and also that a lot of experience and expertise goes into learning why and how, but I'm still left struggling to understand what needs to be disposed. Once I understand what I have to dispose(), then I can begin the struggle to learn how to do it.
Dispose things that implement IDisposable by calling Dispose().
So is this still a bad question?
It is a very repetitive question.
Your patience is a kindness.
Thanks for taking this somewhat silly answer in the humour in which it was intended!
WRT scope != lifetime & variables != objects, very helpful.
These are very commonly confused, and most of the time, it makes little difference. But I find that often people who are struggling to understand a concept are not at all well served by vagueness and imprecision.
In VS is it so simple as looking in Object Browser / Intellisense to see if the object includes Dispose()?
The vast majority of the time, yes.
There are some obscure corner cases. As I already mentioned, the received wisdom from the TPL team is that disposing Task objects is not only unnecessary, but can be counterproductive.
There are also some types that implement IDisposable, but use the "explicit interface implementation" trick to make the "Dispose" method only accessible by casting to IDisposable. In the majority of these cases there is a synonym for Dispose on the object itself, typically called "Close" or some such thing. I don't much like this pattern, but some people use it.
For those objects, the using block will still work. If for some reason you want to explicitly dispose such objects without using using then either (1) call the "Close" method, or whatever it is called, or (2) cast to IDisposable and dispose it.
The general wisdom is: if the object is disposable then it does not hurt to dispose it, and it is a good practice to do so when you're done with it.
The reason being: disposable objects often represent a scarce shared resource. A file, for example, might be opened in a mode that denies the rights of other processes to access that file while you have it opened. It's the polite thing to do to ensure that the file is closed as soon as you're done with it. If one process wanted to use a file, odds are pretty good another one will soon.
Or a disposable might represent something like a graphics object. The operating system will stop giving out new graphics objects if there are more than ten thousand active in a process, so you've got to let them go when you're done with them.
WRT implementing IDisposable #Brian's comment suggests in "normal" coding I likely don't need to. So would I only do that if my class pulled in something unmanaged?
Good question. There are two scenarios in which you should implement IDisposable.
(1) The common scenario: you are writing an object that holds onto another IDisposable object for a long time, and the lifetime of the "inner" object is the same as the lifetime of the "outer" object.
For example: you are implementing a logger class that opens a log file and keeps it open until the log is closed. Now you have a class that is holding onto a disposable, and so it itself should also be disposable.
I note that there is no need in this case for the "outer" object to be finalizable. Just disposable. If for some reason the dispose is never called on the outer object, the finalizer of the inner object will take care of finalization.
(2) the rare scenario: you are implementing a new class which asks the operating system or other external entity for a resource that must be aggressively cleaned up, and the lifetime of that resource is the same as the lifetime of the object holding onto it.
In this exceedingly rare case you should first, ask yourself if there is any way to avoid it. This is a bad situation to be in for a beginner-to-intermediate programmer. You really need to understand how the CLR interacts with unmanaged code in order to get this stuff solid.
If you cannot avoid it, you should prefer to not attempt to implement the disposal and finalization logic yourself, particularly if the unmanaged object is represented by a Windows handle. There should already be wrappers around most of the OS services represented by handles, but if there is not one, what you want to do is carefully study the relationship between IntPtr, SafeHandle and HandleRef. IntPtr, SafeHandle and HandleRef - Explained
If you really truly do need to write the disposal logic for an unmanaged, non-handle-based resource, and the resource requires backstopping the disposal with finalization, then you have a significant engineering challenge.
The standard dispose pattern code may look simple but there are real subtleties to writing correct finalization logic that is robust in the face of error conditions. Remember, a finalizer runs on a different thread and can run on that thread concurrent with the constructor in thread abort scenarios. Writing threadsafe logic which cleans up an object while it is still being constructed on another thread can be extraordinarily difficult and I recommend against trying.
For more on the challenges of writing finalizers, see my series of articles on the subject: http://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/
A question you did not ask but I will answer anyways:
Are there scenarios in which I should not be implementing IDisposable?
Yes. Many people implement IDisposable any time they wish to have a coding pattern that has the semantics of:
Make a change in the world
Do stuff in the new world
Revert the change
So, for example, "impersonate an administrator, do some admin tasks, revert to normal user". Or "start handling an event, do stuff when the event happens, stop handling the event". Or "create an in-memory error tracker, do some stuff that might make errors, stop tracking errors". And so on. You get the general pattern.
This is a poor fit for the disposable pattern, but that doesn't stop people from writing up classes that represent no unmanaged resource whatsoever, but still implement IDisposable as though they did.
This opinion puts me in a minority; lots of people have no problem whatsoever with this abuse of the mechanism. But when I see a disposable I think "the author of this class wishes me to be polite and clean up after myself when I am good and ready." But the actual contract of the class is often "you must dispose this at a particular point in the program and if you do not then the rest of the program logic will be wrong until you do". That is not the contract I expect to have to implement when I see a disposable. I expect that I have to make a good-faith effort to clean up a resource at my convenience.

If you have an object that implements IDisposable then you must always explicitly call .Dispose() on that object. If it doesn't implement IDisposable then obviously you don't call .Dispose() because you can't.
If you are writing your own objects then the rule as to whether or not to implement IDisposable is simply this: If your object holds references to unmanaged objects OR if it holds references to objects that implement IDisposable then it must implement IDisposable.
The GC never calls .Dispose() for you. You must always do it - either directly or through a finalizer.
The GC may (most likely, but not always) call a finalizer, so you can write a finalizer to call dispose, but be careful that you implement the disposable pattern correctly, and be certain that you understand that the finalizer may not ever run so if your dispose method does something vitally important it might be better to call .Dispose() directly before you lose the reference to the object.

The garbage collector (GC) guarantees that managed memory resources that are no longer used are released before the memory limit is reached.
Let's break that down:
managed: Loosely, this means resources entirely within .NET/CLR. Memory allocated by non-.NET C++ libraries, for example, are not released by the GC.
memory: The GC only provides a guarantee on memory usage. Many other resource types exist, such as file handles. The GC has no logic to ensure file handles are released expediently.
no longer used: This means that all variables with a reference to that memory have ended their lifetime. As Eric Lippert explained, lifetime != scope.
before the memory limit is reached: The GC monitors "memory pressure" and makes sure to release memory when needed. It uses a bunch of algorithms to decide when it is most efficient to do this, but it's important to note that the GC decides when to release resources all on its own (nondeterministically to your program).
This leaves us with several scenarios when relying on the GC is not appropriate:
The object references unmanaged resources (including referencing a managed object that references an unmanaged resource).
The object references a resource other than memory that must be released.
The object references a resource that must be released at a specific point in the code (deterministically).
In any of these cases, the object should implement IDisposable to handle resource cleanup.
Any object instantiated that implements IDisposable must be cleaned up by either calling Dispose or using the using block (which takes care of calling Dispose for you).

The Dispose pattern can be used to clear both managed and unmanaged resources. If you have unmanaged resources in your class, according to the proper IDisposable implementation you must have both Dispose and Finalize methods.
How do I know what GC knows/doesn't?
GC knows/interested only about managed objects. GC is supposed to clear objects those don’t have any strong references. It doesn’t know about your logics. For a simple and obvious example.
Let’s say you have a MainView instance which is a lasting a long time and you create another LittleView that subscribe to an event in the MainView instance.
Then you close the LittleView and it disappears. You know that you don’t need that LittleView instance anymore. But GC doesn’t know if you still need LittleView or not as there is an active event subscription to the MainWindow.
So, GC will not bother to clear LittleView instance from memory. So, what you should do is unsubscribe the event when you close the view. Then GC knows that there are no strong references to the LittleView and it’s reachable.
The post also complicates things saying managed resources may include
unmanaged resources. Wow. This is getting deeper than I initially
imagined. I'm still looking to easily recognize how to know what needs
to be disposed. Is it the case this is a complicated list w/
conditions and context?
That’s correct, managed objects also can have unmanaged resources. All those managed objects have their finalize method to clear umanaged resources.
Wonder why you need finalize method in addition to the Dispose?
Unmanaged resources can create the most dangerous memory leaks as such memory leaks can hold on to memory until you restart the PC. So, they are very bad.
Let’s say there is managed instance InsA with some unmanaged. InsA has implemented the Dispose method in a way to clear unmanaged resources too. But what will happen if you don’t/forget to call the Dispose method? It will never clear that unmanaged memory. That’s why Finalization has come in to the functionality. So, if you forget/don’t call the Dispose, finalization will gurantee to execute the Dispose in a way that it release unmanaged resources.

IDisposable for convenience? [duplicate]

I was having a discussion with a colleague recently about the value of Dispose and types that implement IDisposable.
I think there is value in implementing IDisposable for types that should clean up as soon as possible, even if there are no unmanaged resources to clean up.
My colleague thinks differently; implementing IDisposable if you don't have any unmanaged resources isn't necessary as your type will eventually be garbage collected.
My argument was that if you had an ADO.NET connection that you wanted to close as soon as possible, then implementing IDisposable and using new MyThingWithAConnection() would make sense. My colleage replied that, under the covers, an ADO.NET connection is an unmanaged resource. My reply to his reply was that everything ultimately is an unmanaged resource.
I am aware of the recommended disposable pattern where you free managed and unmanaged resources if Dispose is called but only free unmanaged resources if called via the finalizer/destructor (and blogged a while ago about how to alert consumers of improper use of your IDisposable types)
So, my question is, if you've got a type that doesn't contain unmanaged resources, is it worth implementing IDisposable?

There are different valid uses for IDisposable. A simple example is holding an open file, which you need to be closed at certain moment, as soon as you don't need it any more. Of course, you could provide a method Close, but having it in Dispose and using pattern like using (var f = new MyFile(path)) { /*process it*/ } would be more exception-safe.
A more popular example would be holding some other IDisposable resources, which usually means that you need to provide your own Dispose in order to dispose them as well.
In general, as soon as you want to have deterministic destruction of anything, you need to implement IDisposable.
The difference between my opinion and yours is that I implement IDisposable as soon as some resource needs deterministic destruction/freeing, not necessary as soon as possible. Relying on garbage collection is not an option in this case (contrary to your colleague's claim), because it happens at unpredictable moment of time, and actually may not happen at all!
The fact that any resource is unmanaged under the cover really doesn't mean anything: the developer should think in terms of "when and how is it right to dispose of this object" rather than "how does it work under the cover". The underlying implementation may change with the time anyway.
In fact, one of the main differences between C# and C++ is the absence of default deterministic destruction. The IDisposable comes to close the gap: you can order the deterministic destruction (although you cannot ensure the clients are calling it; the same way in C++ you cannot be sure that the clients call delete on the object).
Small addition: what is actually the difference between the deterministic freeing the resources and freeing them as soon as possible? Actually, those are different (though not completely orthogonal) notions.
If the resources are to be freed deterministically, this means that the client code should have a possibility to say "Now, I want this resource freed". This may be actually not the earliest possible moment when the resource may be freed: the object holding the resource might have got everything it needs from the resource, so potentially it could free the resource already. On the other hand, the object might choose to keep the (usually unmanaged) resource even after the object's Dispose ran through, cleaning it up only in finalizer (if holding the resource for too long time doesn't make any problem).
So, for freeing the resource as soon as possible, strictly speaking, Dispose is not necessary: the object may free the resource as soon as it realizes itself that the resource is not needed any more. Dispose however serves as a useful hint that the object itself is not needed any more, so perhaps the resources may be freed at that point if appropriate.
One more necessary addition: it's not only unmanaged resources that need deterministic deallocation! This seems to be one of key points of the difference in opinions among the answers to this question. One can have purely imaginative construct, which may need to be freed deterministically.
Examples are: a right to access some shared structure (think RW-lock), a huge memory chunk (imagine that you are managing some of the program's memory manually), a license for using some other program (imagine that you are not allowed to run more than X copies of some program simultaneously), etc. Here the object to be freed is not an unmanaged resource, but a right to do/to use something, which is a purely inner construct to your program logic.
Small addition: here is a small list of neat examples of [ab]using IDisposable: http://www.introtorx.com/Content/v1.0.10621.0/03_LifetimeManagement.html#IDisposable.

I think it's most helpful to think of IDisposable in terms of responsibilities. An object should implement IDisposable if it knows of something that will need to be done between the time it's no longer needed and the end of the universe (and preferably as soon as possible), and if it's the only object with both the information and impetus to do it. An object which opens a file, for example, would have a responsibility to see that the file gets closed. If the object were to simply disappear without closing the file, the file might not get closed in any reasonable timeframe.
It's important to note that even objects which only interact with 100% managed objects can do things that need to be cleaned up (and should use IDisposable). For example, an IEnumerator which attaches to a collection's "modified" event will need to detach itself when it is no longer needed. Otherwise, unless the enumerator uses some complex trickery, the enumerator will never be garbage-collected as long as the collection is in scope. If the collection is enumerated a million times, a million enumerators would get attached to its event handler.
Note that it's sometimes possible to use finalizers for cleanup in cases where, for whatever reason, an object gets abandoned without Dispose having been called first. Sometimes this works well; sometimes it works very badly. For example, even though Microsoft.VisualBasic.Collection uses a finalizer to detach enumerators from "modified" events, attempting to enumerate such an object thousands of times without an intervening Dispose or garbage-collection will cause it to get very slow--many orders of magnitude slower than the performance that would result if one used Dispose correctly.

So, my question is, if you've got a type that doesn't contain
unmanaged resources, is it worth implementing IDisposable?
When someone places an IDisposable interface on an object, this tells me that the creator intends on this either doing something in that method or, in the future they may intend to. I always call dispose in this instance just to be sure. Even if it doesn't do anything right now, it might in the future, and it sucks to get a memory leak because they updated an object, and you didn't call Dispose when you were writing code the first time.
In truth it's a judgement call. You don't want to over implement it, because at that point why bother having a garbage collector at all. Why not just manually dispose every object. If there is a possibility that you'll need to dispose unmanaged resources, then it might not be a bad idea. It all depends, if the only people using your object are the people on your team, you can always follow up with them later and say, "Hey this needs to use an unmanaged resource now. We have to go through the code and make sure we've tidied up." If you are publishing this for other organizations to use that's different. There is no easy way to tell everyone who might have implemented that object, "Hey you need to be sure this is now disposed." Let me tell you there are few things that make people madder than upgrading a third party assembly to find out that they are the ones who changed their code and made your application have run away memory problems.
My colleage replied that, under the covers, an ADO.NET connection is a
managed resource. My reply to his reply was that everything ultimately
is an unmanaged resource.
He's right, it's a managed resource right now. Will they ever change it? Who knows, but it doesn't hurt to call it. I don't try and make guesses as to what the ADO.NET team does, so if they put it in and it does nothing, that's fine. I'll still call it, because one line of code isn't going to affect my productivity.
You also run into another scenario. Let's say you return an ADO.NET connection from a method. You don't know that ADO connection is the base object or a derived type off the bat. You don't know if that IDisposable implementation has suddenly become necessary. I always call it no matter what, because tracking down memory leaks on a production server sucks when it's crashing every 4 hours.

While there are good answers to this already, I just wanted to make something explicit.
There are three cases for implementing IDisposable:
You are using unmanaged resources directly. This typically involves retrieving an IntPrt or some other form of handle from a P/Invoke call that has to be released by a different P/Invoke call
You are using other IDisposable objects and need to be responsible for their disposition
You have some other need of or use for it, including the convenience of the using block.
While I might be a bit biased, you should really read (and show your colleague) the StackOverflow Wiki on IDisposable.

Dispose should be used for any resource with a limited lifetime. A finalizer should be used for any unmanaged resource. Any unmanaged resource should have a limited lifetime, but there are plenty of managed resources (like locks) that also have limited lifetimes.

Note that unmanaged resources may well include standard CLR objects, for instance held in some static fields, all ran in safe mode with no unmanaged imports at all.
There is no simple way to tell if a given class implementing IDiposable actually needs to clean something. My rule of thumb is to always call Dispose on objects I don't know too well, like some 3rd party library.

No, it's not only for unmanaged resources.
It's suggested like a basic cleanup built-in mechanism called by framework, that enables you possibility to cleanup whatever resource you want, but it's best fit is naturally unmanaged resources management.

If you aggregate IDisposables then you should implement the interface in order that those members get cleaned up in a timely way. How else is myConn.Dispose() going to get called in the ADO.Net connection example you cite?
I don't think it's correct to say that everything is an unmanaged resource in this context though. Nor do I agree with your colleague.

You are right. Managed database connections, files, registry keys, sockets etc. all hold on to unmanaged objects. That is why they implement IDisposable. If your type owns disposable objects you should implement IDisposable and dispose them in your Dispose method. Otherwise they may stay alive until garbage collected resulting in locked files and other unexpected behavior.

everything ultimately is an unmanaged resource.
Not true. Everything except memory used by CLR objects which is managed (allocated and freed) only by the framework.
Implementing IDisposable and calling Dispose on an object that does not hold on to any unmanaged resources (directly or indirectly via dependent objects) is pointless. It does not make freeing that object deterministic because you can't directly free object's CLR memory on your own as it is always only GC that does that. Object being a reference type because value types, when used directly at a method level, are allocated/freed by stack operations.
Now, everyone claims to be right in their answers. Let me prove mine. According to documentation:
Object.Finalize Method allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.
In other words object's CLR memory is released just after Object.Finalize() is called. [note: it is possible to explicitly skip this call if needed]
Here is a disposable class with no unmanaged resources:
internal class Class1 : IDisposable
{
public Class1()
{
Console.WriteLine("Construct");
}
public void Dispose()
{
Console.WriteLine("Dispose");
}
~Class1()
{
Console.WriteLine("Destruct");
}
}
Note that destructor implicitly calls every Finalize in the inheritance chain down to Object.Finalize()
And here is the Main method of a console app:
static void Main(string[] args)
{
for (int i = 0; i < 10; i++)
{
Class1 obj = new Class1();
obj.Dispose();
}
Console.ReadKey();
}
If calling Dispose was a way to free a managed object in a deterministic way, every "Dispose" would be immediately followed by a "Destruct", right? See for yourself what happens. It is most interesting to run this app from a command line window.
Note: There is a way to force GC to collect all objects which are pending finalization in the current app domain but no for a single specific object. Nevertheless you do not need to call Dispose to have an object in the finalization queue. It is strongly discouraged to force collection as it will likely hurt overall application performance.
EDIT
There is one exception - state management. Dispose can handle state change if your object happens to manage an outside state. Even if state is not an unmanaged object it is very convenient to use it like one because of special treatment IDisposable has. Example would be a security context or impersonation context.
using (WindowsImpersonationContext context = SomeUserIdentity.Impersonate()))
{
// do something as SomeUser
}
// back to your user
It is not the best example because WindowsImpersonationContext uses system handle internally but you get the picture.
Bottom line is that when implementing IDisposable you need to have (or plan to have) something meaningful to do in the Dispose method. Otherwise it's just a waste of time. IDisposable does not change how your object is managed by GC.

Your Type should implement IDisposable if it references unmanaged resources or if it holds references to objects that implement IDisposable.

In one of my projects I had a class with managed threads inside it, we'll call them thread A, and thread B, and an IDisposable object, we'll call it C.
A used to dispose of C on exiting.
B used to use C to save exceptions.
My class had to implement IDisposable and a descrtuctor to ensure things are disposed of in the correct order.
Yes the GC could clean up my items, but my experience was there was a race condition unless I managed the clean up of my class.

Short Answer: Absolutely NOT. If your type has members that are managed or unmanaged, you should implement IDisposable.
Now details:
I've answered this question and provided much more detail on the internals of memory management and the GC on questions here on StackOverflow. Here are just a few:
Is it bad practice to depend on the .NET automated garbage collector?
What happens if I don't call Dispose on the pen object?
Dispose, when is it called?
As far as best practices on the implementation of IDisposable, please refer to my blog post:
How do you properly implement the IDisposable pattern?

Implement IDisposable if the object owns any unmanaged objects or any managed disposable objects
If an object uses unmanaged resources, it should implement IDisposable. The object that owns a disposable object should implement IDisposable to ensure that the underlying unmanaged resources are released. If the rule/convention is followed, it is therefore logical to conclude that not disposing managed disposable objects equals not freeing unmanaged resources.

Not necessary resources at all (either managed or unmanaged). Often, IDisposable is just a convenient way to elimnate combersome try {..} finally {..}, just compare:
Cursor savedCursor = Cursor.Current;
try {
Cursor.Current = Cursors.WaitCursor;
SomeLongOperation();
}
finally {
Cursor.Current = savedCursor;
}
with
using (new WaitCursor()) {
SomeLongOperation();
}
where WaitCursor is IDisposable to be suitable for using:
public sealed class WaitCursor: IDisposable {
private Cursor m_Saved;
public Boolean Disposed {
get;
private set;
}
public WaitCursor() {
Cursor m_Saved = Cursor.Current;
Cursor.Current = Cursors.WaitCursor;
}
public void Dispose() {
if (!Disposed) {
Disposed = true;
Cursor.Current = m_Saved;
}
}
}
You can easily combine such classes:
using (new WaitCursor()) {
using (new RegisterServerLongOperation("My Long DB Operation")) {
SomeLongRdbmsOperation();
}
SomeLongOperation();
}

Should "Dispose" only be used for types containing unmanaged resources?

I was having a discussion with a colleague recently about the value of Dispose and types that implement IDisposable.
I think there is value in implementing IDisposable for types that should clean up as soon as possible, even if there are no unmanaged resources to clean up.
My colleague thinks differently; implementing IDisposable if you don't have any unmanaged resources isn't necessary as your type will eventually be garbage collected.
My argument was that if you had an ADO.NET connection that you wanted to close as soon as possible, then implementing IDisposable and using new MyThingWithAConnection() would make sense. My colleage replied that, under the covers, an ADO.NET connection is an unmanaged resource. My reply to his reply was that everything ultimately is an unmanaged resource.
I am aware of the recommended disposable pattern where you free managed and unmanaged resources if Dispose is called but only free unmanaged resources if called via the finalizer/destructor (and blogged a while ago about how to alert consumers of improper use of your IDisposable types)
So, my question is, if you've got a type that doesn't contain unmanaged resources, is it worth implementing IDisposable?

While there are good answers to this already, I just wanted to make something explicit.
There are three cases for implementing IDisposable:
You are using unmanaged resources directly. This typically involves retrieving an IntPrt or some other form of handle from a P/Invoke call that has to be released by a different P/Invoke call
You are using other IDisposable objects and need to be responsible for their disposition
You have some other need of or use for it, including the convenience of the using block.
While I might be a bit biased, you should really read (and show your colleague) the StackOverflow Wiki on IDisposable.

Dispose should be used for any resource with a limited lifetime. A finalizer should be used for any unmanaged resource. Any unmanaged resource should have a limited lifetime, but there are plenty of managed resources (like locks) that also have limited lifetimes.

Note that unmanaged resources may well include standard CLR objects, for instance held in some static fields, all ran in safe mode with no unmanaged imports at all.
There is no simple way to tell if a given class implementing IDiposable actually needs to clean something. My rule of thumb is to always call Dispose on objects I don't know too well, like some 3rd party library.

No, it's not only for unmanaged resources.
It's suggested like a basic cleanup built-in mechanism called by framework, that enables you possibility to cleanup whatever resource you want, but it's best fit is naturally unmanaged resources management.

If you aggregate IDisposables then you should implement the interface in order that those members get cleaned up in a timely way. How else is myConn.Dispose() going to get called in the ADO.Net connection example you cite?
I don't think it's correct to say that everything is an unmanaged resource in this context though. Nor do I agree with your colleague.

You are right. Managed database connections, files, registry keys, sockets etc. all hold on to unmanaged objects. That is why they implement IDisposable. If your type owns disposable objects you should implement IDisposable and dispose them in your Dispose method. Otherwise they may stay alive until garbage collected resulting in locked files and other unexpected behavior.

everything ultimately is an unmanaged resource.
Not true. Everything except memory used by CLR objects which is managed (allocated and freed) only by the framework.
Implementing IDisposable and calling Dispose on an object that does not hold on to any unmanaged resources (directly or indirectly via dependent objects) is pointless. It does not make freeing that object deterministic because you can't directly free object's CLR memory on your own as it is always only GC that does that. Object being a reference type because value types, when used directly at a method level, are allocated/freed by stack operations.
Now, everyone claims to be right in their answers. Let me prove mine. According to documentation:
Object.Finalize Method allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.
In other words object's CLR memory is released just after Object.Finalize() is called. [note: it is possible to explicitly skip this call if needed]
Here is a disposable class with no unmanaged resources:
internal class Class1 : IDisposable
{
public Class1()
{
Console.WriteLine("Construct");
}
public void Dispose()
{
Console.WriteLine("Dispose");
}
~Class1()
{
Console.WriteLine("Destruct");
}
}
Note that destructor implicitly calls every Finalize in the inheritance chain down to Object.Finalize()
And here is the Main method of a console app:
static void Main(string[] args)
{
for (int i = 0; i < 10; i++)
{
Class1 obj = new Class1();
obj.Dispose();
}
Console.ReadKey();
}
If calling Dispose was a way to free a managed object in a deterministic way, every "Dispose" would be immediately followed by a "Destruct", right? See for yourself what happens. It is most interesting to run this app from a command line window.
Note: There is a way to force GC to collect all objects which are pending finalization in the current app domain but no for a single specific object. Nevertheless you do not need to call Dispose to have an object in the finalization queue. It is strongly discouraged to force collection as it will likely hurt overall application performance.
EDIT
There is one exception - state management. Dispose can handle state change if your object happens to manage an outside state. Even if state is not an unmanaged object it is very convenient to use it like one because of special treatment IDisposable has. Example would be a security context or impersonation context.
using (WindowsImpersonationContext context = SomeUserIdentity.Impersonate()))
{
// do something as SomeUser
}
// back to your user
It is not the best example because WindowsImpersonationContext uses system handle internally but you get the picture.
Bottom line is that when implementing IDisposable you need to have (or plan to have) something meaningful to do in the Dispose method. Otherwise it's just a waste of time. IDisposable does not change how your object is managed by GC.

Your Type should implement IDisposable if it references unmanaged resources or if it holds references to objects that implement IDisposable.

In one of my projects I had a class with managed threads inside it, we'll call them thread A, and thread B, and an IDisposable object, we'll call it C.
A used to dispose of C on exiting.
B used to use C to save exceptions.
My class had to implement IDisposable and a descrtuctor to ensure things are disposed of in the correct order.
Yes the GC could clean up my items, but my experience was there was a race condition unless I managed the clean up of my class.

Short Answer: Absolutely NOT. If your type has members that are managed or unmanaged, you should implement IDisposable.
Now details:
I've answered this question and provided much more detail on the internals of memory management and the GC on questions here on StackOverflow. Here are just a few:
Is it bad practice to depend on the .NET automated garbage collector?
What happens if I don't call Dispose on the pen object?
Dispose, when is it called?
As far as best practices on the implementation of IDisposable, please refer to my blog post:
How do you properly implement the IDisposable pattern?

Implement IDisposable if the object owns any unmanaged objects or any managed disposable objects
If an object uses unmanaged resources, it should implement IDisposable. The object that owns a disposable object should implement IDisposable to ensure that the underlying unmanaged resources are released. If the rule/convention is followed, it is therefore logical to conclude that not disposing managed disposable objects equals not freeing unmanaged resources.

Not necessary resources at all (either managed or unmanaged). Often, IDisposable is just a convenient way to elimnate combersome try {..} finally {..}, just compare:
Cursor savedCursor = Cursor.Current;
try {
Cursor.Current = Cursors.WaitCursor;
SomeLongOperation();
}
finally {
Cursor.Current = savedCursor;
}
with
using (new WaitCursor()) {
SomeLongOperation();
}
where WaitCursor is IDisposable to be suitable for using:
public sealed class WaitCursor: IDisposable {
private Cursor m_Saved;
public Boolean Disposed {
get;
private set;
}
public WaitCursor() {
Cursor m_Saved = Cursor.Current;
Cursor.Current = Cursors.WaitCursor;
}
public void Dispose() {
if (!Disposed) {
Disposed = true;
Cursor.Current = m_Saved;
}
}
}
You can easily combine such classes:
using (new WaitCursor()) {
using (new RegisterServerLongOperation("My Long DB Operation")) {
SomeLongRdbmsOperation();
}
SomeLongOperation();
}

IDisposable, Finalizers and the definition of an unmanaged resource

I'm trying to make sure that my understanding of IDisposable is correct and there's something I'm still not quite sure on.
IDisposable seems to serve two purpose.
To provide a convention to "shut down" a managed object on demand.
To provide a convention to free "unmanaged resources" held by a managed object.
My confusion comes from identifying which scenarios have "unmanaged resources" in play.
Say you are using a Microsoft-supplied IDisposable-implementing (managed) class (say, database or socket-related).
How do you know whether it is implementing IDisposable for just 1 or 1&2 above?
Are you responsible for making sure that unmanaged resources it may or may not hold internally are freed? Should you be adding a finalizer (would that be the right mechanism?) to your own class that calls instanceOfMsSuppliedClass.Dispose()?

How do you know whether it is implementing IDisposable for just 1 or
1&2 above?
The answer to your first question is "you shouldn't need to know". If you're using third party code, then you are its mercy to some point - you'd have to trust that it's disposing of itself properly when you call Dispose on it. If you're unsure or you think there's a bug, you could always try using Reflector() to disassemble it (if possible) and check out what it's doing.
Am I responsible for making sure that unmanaged resources it may or may
not hold internally are freed? Should
I be adding a finalizer (would that be
the right mechanism?) to my own class
that calls
instanceOfMsSuppliedClass.Dispose()?
You should rarely, if ever, need to implement a finalizer for your classes if you're using .Net 2.0 or above. Finalizers add overhead to your class, and usually provide no more functionality then you'd need with just implementing Dispose. I would highly recommend visiting this article for a good overview on disposing properly. In your case, you would want to call instanceofMSSuppliedClass.Dispose() in your own Dispose() method.
Ultimately, calling Dispose() on an object is good practice, because it explictly lets the GC know that you're done with the resource and allows the user the ability to clean it up immediately, and indirectly documents the code by letting other programmers know that the object is done with the resources at that point. But even if you forget to call it explicitly, it will happen eventually when the object is unrooted (.Net is a managed platform after all). Finalizers should only be implemented if your object has unmanaged resources that will need implicit cleanup (i.e. there is a chance the consumer can forget to clean it up, and that this will be problematic).

You should always call Dispose on objects that implement IDisposable (unless they specifically tell you' it's a helpful convention, like ASP.NET MVC's HtmlHelper.BeginForm). You can use the "using" statement to make this easy. If you hang on to a reference of an IDisposable in your class as a member field then you should implement IDisposable using the Disposable Pattern to clean up those members. If you run a static-analysis tool like FxCop it will tell you the same.
You shouldn't be trying to second-guess the interface. Today that class might not use an unmanaged resource but what about the next version?

You're not responsible for the contents of an object. Dispose() should be transparent, and free what it needs to free. After that, you're not responsible for it.
Unmanaged resources are resources like you would create in (managed) C++, where you allocate memory through pointers and "new" statements, rather than "gcnew" statements. When you're creating a class in C++, you're responsible for deleting this memory, since it is native memory, or unmanaged, and the garbage collector does not about it. You can also create this unmanaged memory through Marshal allocations, and, i'd assume, unsafe code.
When using Managed C++, you don't have to manually implement the IDisposable class either. When you write your deconstructor, it will be compiled to a Dispose() function.

If the class in question is Microsoft-supplied (ie.. database, etc..) then the handling of Dispose (from IDisposable) will most likely already be taken care of, it is just up to you to call it. For instance, standard practice using a database would look like:
//...
using (IDataReader dataRead = new DataReaderObject())
{
//Call database
}
This is essentially the same as writing:
IDataReader dataRead = null;
try
{
dataRead = new DataReaderObject()
//Call database
}
finally
{
if(dataRead != null)
{
dataRead.Dispose();
}
}
From what I understand, it is generally good practice for you use the former on objects that inherit from IDisposable since it will ensure proper freeing of resources.
As for using IDisposable yourself, the implementation is up to you. Once you inherit from it you should ensure the method contains the code needed to dispose of any DB connections you may have manually created, freeing of resources that may remain or prevent the object from being destroyed, or just cleaning up large resource pools (like images). This also includes unmanaged resources, for instance, code marked inside an "unsafe" block is essentially unmanaged code that can allow for direct memory manipulation, something that definitely needs cleaning up.

The term "unmanaged resource" is something of a misnomer. The essential concept is that of a paired action--performing one action creates a need to perform some cleanup action. Opening a file creates a need to close it. Dialing a modem creates a need to hang up. A system may survive a failure to perform a cleanup operation, but the consequences may be severe.
When an object is said to "hold unmanaged resources", what is really meant is that the object has the information and impetus necessary to perform some required cleanup operation on some other entity, and there's no particular reason to believe that information and impetus exists anywhere else. If the only object with such information and impetus is completely abandoned, the required cleanup operation will never occur. The purpose of .Dispose is to force an object to perform any required cleanup, so that it may be safely abandoned.
To provide some protection against code which abandons objects without first calling Dispose, the system allows classes to register for "finalization". If an object of a registered class is abandoned, the system will give the object a chance to perform cleanup operation on other entities before it is abandoned for good. There's no guarantee as to how quickly the system will notice that an object has been abandoned, however, and various circumstances may prevent an object from being offered its chance to clean up. The term "managed resource" is sometimes used to refer to an object which will have to perform some cleanup before it's abandoned, but which will automatically register and attempt to perform such cleanup if someone fails to call Dispose.

Why should it matter to you?
When possible I wrap the scope of a disposable object in a using. This calls dispose at the end of the using. When not I explicitly call dispose whenever I no longer need the object.
Whether for reason 1 or reason 2 is not necessary.

Yes, you're responsible to call the Dispose method - or better use using statement. If an object is implementing IDisposable, you should always dispose it, no matter what.
using (var myObj = new Whatever())
{
// ..
}
is similar to
{
var myObj;
try
{
myObj = new Whatever();
// ..
}
finally
{
if (myObj != null)
{
((IDisposable)myObj).Dispose();
}
}
} // object scope ends here
EDIT: Added try/finally thanks to Talljoe - wow, that's complicated to get it right :)
EDIT2: I am not saying that you should use the second variant. I just wanted to show that "using" is nice syntactic sugar for a bunch of code that can get quite messy and hard to get right.

One piece that is missing here is the finalizer - my habit has been if I implement IDisposable I also have a finalizer to call Dispose() just in case my client doesn't. Yes, it adds overhead but if Dispose() IS called than the GC.SuppressFinalize(this) call eliminates it.

When does CLR say that an object has a finalizer?

I know that in C#, if you write ~MyClass(), this basically translates to override System.Object.Finalize(). So, whether you write the destructor or not, every type in CLR will have a Finalize() method in it (of System.Object at least).
1] So, does it mean that, every object, by default, has a finalizer ?
2] What is the basis for the CLR to decide that an object should be put through finalization queue ?
I'm asking this, because, I had a class, say ManagedResourceHolder that implemented IDisposable, but did not call GC.SuppressFinalize(this) in its IDisposable.Dispose() method. The class did not hold any unmanaged resources, and there was no need for the ~ManagedResourceHolder() method, which in turn meant no need for the GC.SuppressFinalize(this) call as there was no finalizer.
3] In context of the above scenario, is it always necessary to provide a finalizer when you implement IDisposable ? (even on a class that holds no unmanaged resources)
The FxCop rule CA1816 was giving me a violation on this and the response I got here when I asked in the CA forum on MSDN confused me.
Thanks.

Questions 1 and 2: The CLR basically checks whether or not the finalizer is overridden. If it's not, it treats it as not having a finalizer.
The benefit of having a finalizer in System.Object is that compilers know they can always put a call to base.Finalize() in. This avoids versioning issues. Consider a world without System.Object.Finalize():
System.Object (no Finalize)
Acme.BaseClass (no Finalize)
MyCompany.DerivedClass (Finalize)
Without a Finalize method in object, the finalizer in MyCompany.DerivedClass can't call anything. Which leads to a problem when version 2 of Acme.BaseClass comes out with a finalizer. Unless you recompile MyCompany.DerivedClass, an instance of DerivedClass will be finalized without calling BaseClass.Finalize, which is clearly a Bad Thing.
Now consider the same situation with System.Object.Finalize - the compiler inserts a call to base.Finalize automatically in DerivedClass.Finalize, which in version 1 just calls the no-op implementation in System.Object. When version 2 of Acme.BaseClass comes out, the call to base.Finalize will (without recompilation of DerivedClass) call BaseClass.Finalize.
Question 3: No, you don't need to have a finalizer just because you implement IDisposable. Finalizers should only be used for unmanaged resources which nothing else is going to clean up - i.e. ones you have a direct reference to. For instance, suppose you have a class which has a FileStream member variable. You want to implement IDisposable so you can close the stream as soon as possible, if the caller remembers - but if they don't remember to call Dispose(), the stream will become eligible for garbage collection at the same time as your object. Trust that FileStream has an appropriate finalizer (or a reference to something else with a finalizer etc) rather than trying to clean it up in your own finalizer.
As of .NET 2.0, with the SafeHandle class, it should be incredibly rare for you to need your own finalizer.

1: It only really counts (in the useful sense) if it has been overridden
2: As defined by 1, and GC.SuppressFinalize has not been called (plus re-register etc)
3: certainly not; in fact, unless you are directly handling an unmanaged resource, you shouldn't have a finalizer. You shouldn't add a finalizer just because it is IDisposable - but things that have finalizers should also generally be IDisposable.

Nope, it doesn't mean so. Only overridden Finalize() will count by the CLR.
By having a finalizer, as defined above.
Nope, it's not always necessary. It's just a nice pattern. I mean, nobody forces you to do so. But it's a good thing to do if you have unmanaged resources, since if somebody forgets to dispose it, the unmanaged resource will get released sometime. FxCop does not enforce strict rules. It enforces good patterns that may lead to failure in the future if you don't take care of.
UPDATE: Every class is responsible for managing its own resources. Due to abstraction and encapsulation features of object-oriented paradigms, the consumer of a class should not care about what resources it has, indirectly. Therefore, you should either manually release the resources you own (what you own is what you directly own as you look at other things as a black box) or leave it to the GC to release them. For unmanaged resources, you don't have the option to leave it to the GC, so you have to release it manually. In this sense, a SafeHandle that Jon mentioned is a managed abstraction of an unmanaged resource, therefore it should be treated as a valuable managed resource (which is a black box that manages the finalization of that unmanaged resource itself).

1) Yes (by virtue of inheritance)
2) Nothing is holding a reference to the instance of a class (that will make it eligible for finalization)
3) Yes (why should one implement IDisposable unless it is requiring the user to explicitly call dispose? Connection classes in .net use an umanaged resource under the hood & if you don't call dispose on it, it will hang on to it. Since the GC timing is unknown, the connection will remain open till that time)
This is my understanding.
I could be wrong.
In which case, experts will correct things out for me.

We Keep Coding

C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.