When to call Dispose

When to call Dispose | MS Tech News

When to call Dispose | MS Tech News — Thu, 06 Nov 2008 09:45:53 GMT

PingBack from http://mstechnews.info/2008/11/when-to-call-dispose/

re: When to call Dispose

Bradley Grainger — Thu, 06 Nov 2008 17:24:27 GMT

Hi Kim,

There's another Dispose-related special case: "IDisposable is not implemented correctly".

IDisposable on ClientBase<T> (from WCF) is implemented in a way that can sometimes cause it to throw (which violates the "Dispose should never throw" guideline for implementing the dispose pattern).

The official guideline for WCF clients (http://msdn.microsoft.com/en-us/library/aa355056.aspx) now recommends that the "using" statement not be used (and thus Dispose not be called), and instead suggests a complicated series of multiple catch blocks.

In a forum post (http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/b95b91c7-d498-446c-b38f-ef132989c154), Brian McNamara wrote, "You can argue (and some of us did) that we should have removed [IDisposable] from those two classes [ServiceHost and ClientBase]", indicating that perhaps the implementation of IDisposable on these WCF classes was a mistake.

re: When to call Dispose

Bradley Grainger — Thu, 06 Nov 2008 17:33:40 GMT

As I'm sure you know, there is a cost to letting the finalizer clean up finalizable objects. (Chris Brumme goes into some reasons at http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspx, which include promotion of objects, or possibly object graphs, to the next GC generation, and the current CLR only having one finalizer thread, which can limit scalability.)

Thus, I would suggest adding another reason to call Dispose to category #2: When the cost of finalization is measurably affecting performance or memory use.

re: When to call Dispose

Ziv Caspi — Thu, 06 Nov 2008 19:29:07 GMT

I would argue that it's WinForm that's at fault for not using the IDisposable contract correctly. They should simply have called their method something else, since not calling Dispose in this case is non-observable.

Interesting Finds: 2008.11.01~2008.11.07

gOODiDEA.NET — Fri, 07 Nov 2008 03:46:55 GMT

.NET What's New in the BCL in .NET 4.0 NetMon API – Capture, Parse and and Capture File Access

Interesting Finds: 2008.11.01~2008.11.07

gOODiDEA — Fri, 07 Nov 2008 03:49:57 GMT

.NETWhat'sNewintheBCLin.NET4.0NetMonAPI–Capture,ParseandandCaptureFileAccess(wi...

re: When to call Dispose

kimhamil — Fri, 07 Nov 2008 11:02:12 GMT

Hi Bradley,

It was nice to meet you at PDC last week. I wasn't aware of the WCF ServiceHost and ClientBase examples. I read the forum post and it's interesting that matching up Close and Dispose (after the fact) was involved in this behavior. It's indeed a common expectation that they do the same. As I talked about in another post, I believe we'd have fewer Dispose headaches if we'd never given the guidance of hiding Dispose in favor of domain-specific names.

Finalization cost is an interesting point. It will be important to clarify that for category 2, we're just saying that calling Dispose isn't necessary from a correctness standpoint, as opposed to "don't call Dispose". There are cases where users would want to.

Thanks,

Kim

re: When to call Dispose

kimhamil — Fri, 07 Nov 2008 11:05:43 GMT

Hi Ziv,

Unfortunately not calling Dispose _could_ be observable in extreme cases. Best example I can think of would be a targeted stress test. :) These are cases where it's hard to hit the limits, but we want to make sure apps that happen to do this are aware of the problem.

Thanks,

Kim

re: When to call Dispose

Mike Dimmick — Thu, 13 Nov 2008 13:31:21 GMT

In WinForms, controls that are owned by another control (in that control's Controls collection, either by calling .Add or by setting the control's Parent property) are disposed automatically when that control is itself disposed. Top-level forms are disposed when the window is destroyed. This largely means that the programmer doesn't have to do anything. However, there is no Destroy method - you destroy a window by calling Dispose.

In addition, any non-graphical components added to a form in Visual Studio's designer cause VS to generate code that adds them to a System.ComponentModel.Container named 'components', and an override of Dispose which disposes the container, which in turn disposes all of the contained components. This works for desktop apps but is BROKEN for smart device development (Compact Framework). I added a bug on this - Connect feedback ID 305534 - which has STILL had no reply after more than a year.

On Compact Framework you don't have space for VM overflows, particularly on Windows Mobile 5.0 devices where there is often a tiny amount of VM actually available, due to the DLL loading model and vast number of eXecute In Place DLLs. Calling Dispose everywhere is absolutely required. Leaving it to Finalize is too late.

re: When to call Dispose

Jérémie Chassaing — Mon, 17 Nov 2008 12:24:08 GMT

A typical ambiguous case can be found with readers and writers (StreamReader, StreamWriter, BinaryReader, BinaryWriter...).

They implement IDisposable just in case the have ownership on the underlying stream, but the documentation is not clear about it.

When you need to keep the stream open (to use several differents writers, or when using a memory stream), you must use Flush and not Close (= Dispose).

My opinion is that you should always call Flush, and then call Dispose only if you need to get rid of the underlying stream.

A bit confusing...