Yes. If the API you’re using is written properly, you don’t need a finalizer. The reason for this is that, as soon as your “wrapper” class would be finalized, any managed references (the internal API handle) are also eligible for finalization, and the IDisposable implementation there should handle the closing automatically.

Adding a finalizer in your class would really have no effect, and just decrease performance.

If, however, you are finding that the connection is not being closed because the internal implementation is written improperly, you could add a finalizer and close it explicitly – but this really shouldn’t be required.

-Reed

Thank you very much for your commitment to the developer community.

I am still wrangling with what to do in my particular situation…
I have written a class that encapsulates API functionality for an external system. Creating the connection is costly — consistently takes 6 to 7 seconds to connect — so I am creating the connection in the constructor and leaving it open for the object’s brief lifetime (it is for a web application). (During its lifetime, several methods are repetitively called, and performance would be horrible if I opened and closed the connection within each method.)

The API object does have a Disconnect() and Dispose() method and I am exposing my own Disconnect() method and implementing IDispose. Good form would be for the user of my class to always Disconnect() and Dispose(), but of course there is no way to guarantee that will happen.

From what I’ve read, it seems I can assume that the API object itself will be disposed of on its own since it is a manged resource. Would that be correct?

More importantly, however, I do want to be sure that connection is always explicitly closed first. Even though I have no unmanaged resources, is this a case where a destructor is definitely needed? And I assume that I would check for and close the open connection regardless of whether Dispose(bool) was called with True or False?

If you have sample code that illustrates this scenario, that would be awesome:
1. Class (can be sealed if that helps) with a private class-level variable that contains an open connection to something (connection made in the constructor).
2. The Class exposes Disconnect() and implements IDispose.
3. Code is in place to reliably ensure that the connection will be closed if the user of the class neglected to do so.

Another thing I wonder is, do I need to implement IDispose at all? Is it dangerous/stupid to assume that the API object is smart enough to internally close the connection itself when it is disposed/finalized?

Thank you again!

Thanks for the feedback!

I’m glad the post is helping. The series on IDisposable was probably my favorite, up until my new MVVM one Both are trying to tackle a subject that’s been talked about a lot, but take it on from a slightly different angle, in a bit more depth. I hope you find them useful.

-Reed

Thanks for explaining it clearly, I just forgot the purpose of the IDisposable interface. Actually, here AFactory class implements IDisposable interface to make it can be release it’s managed resources explicitly.

Keep your good work, I decide to go through all your MVVM articles. Actually, I get to know you in msdn forums, and find you can always explaining tech in clear words, and your suggestions in the blogs are very helpful.

It won’t be a problem. If AFactory is every a candidate for finalization, that means that all of its private managed resources (in this case, LicenseGenerator) will also be candidates for finalization. When LicenseGenerator’s finalizer runs, it will dispose of the unmanaged resource. There is no need for an explicit finalizer in AFactory, only in LicenseGenerator.

This is why, when encapsulating an IDisposable, you don’t need a finalizer – even though you still want to be IDisposable, and why the pattern is differnet in this case. If you directly contain a native resource, you need a finalizer – otherwise, you typically do not need one.

In this case, if the user forgets to call the dispose method of AFactory, unmanaged resources of LicenseGenerator will not be released. While in pattern1 and partter2. the finalizer will call dispose(false) to dispose unmanned resource when they forget to. Will this be a problem?