Dispose Again!

[David]

Re: Dispose Again!

On 2005-03-22, Scott M. <s-mar@nospam.nosp am> wrote:[color=blue][color=green]
>> Your saying that Dispose is present because of the IDE and not the final
>> running application and that in that final running application, Dispose
>> has
>> no use.[/color]
>[color=green][color=darkred]
>>>>I'm saying that's true in some cases.[/color][/color]
>
> Well, actually you didn't say that the first time,[/color]

Okay, let's see what I actually said...

Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.

That's pretty straightforward . Some objects need runtime disposing, but
there's a lot of objects that don't, even if those objects might need
design-time disposing.

Originally you disagreed that this was even possible. Do you still hold
that opinion?

you said:[color=blue]
>[color=green][color=darkred]
>>> Web controls are the perfect example of that. At design time, they need
>>> to be disposed otherwise you'll squander windows resources. But at
>>> runtime, there's nothing to dispose. Also, if you think about it,
>>> there's no reasonable time for user code to dispose a web control at
>>> runtime (Page.Unload maybe?).[/color][/color]
>
> What I got from this was you saying "you don't need to dispose web form
> controls at run-time". And this is not true. As you say an OleDb
> connection object at run-time will be holding on to unmanaged resources that
> do not have anything to do with GDI and so this connection object should be
> disposed at run-time.[/color]

An OleDbConnection isn't a web control.
[color=blue][color=green]
>> That is what I take issue with, that is what is completely false.[/color]
>[color=green][color=darkred]
>>>>Well, gee, it's hard to argue with that impeccable logic. And you've
>>>>backed up your argument so well here with, well, pretty much nothing.[/color][/color]
>
> And, gee, your sarcasm is something we can do without as well.[/color]

Perhaps you're right.
[color=blue]
> Do you
> disagree that OleDb connections hold unmanaged resources? What part of
> saying that an OleDb connection needs to be disposed at run-time do you
> disagree with?[/color]

Short answer: yes, you should dispose an OleDbConnection at runtime.*


* Longer answer, OleDbConnection is one of the most complex examples
there is. The problem is the subtle differences between Close and
Dispose on an OleDbConnection , and also the effect that Dispose and
FreeCoTaskMem can have on the connection pool and the interface with the
actual DB provider. In truth, I honestly don't know the answer
(although profiling seems to imply that it really doesn't matter much
either way). Mind you, you should definitely *Close* an
OleDbConnection , but Close and Dispose aren't the same thing, despite
what a lot of the docs say.

[David]

Re: Dispose Again!

On 2005-03-22, Michael C# <xyz@yomomma.co m> wrote:[color=blue]
> OK Got it. Learn IL, then use Object Browser and Reflector to observe the
> objects...[/color]

Well, I actually think everyone should know IL anyway :)
[color=blue]
> Y'Know, if someone would just write a book called ".NET Dispose() List" or
> some such crap, with a complete listing of all built-in Framework classes
> that require Dispose to be used, I'd be second in line to buy the damn
> thing. I thought the .NET Framework was going to make life easier - but
> sometimes it seems that old problems were just exchanged for their 21st
> century equivalents.[/color]

Dispose is a tough problem, I'm not disagreeing there. Ideally we'd
have automatic ref counting systemwide and deterministic finalization,
but the technology just isn't there yet.

OTOH, Dispose just isn't something I spend my days worrying about
(unlike C++, for example, where dangling references and object lifetimes
were a constant concern). A few simple ground rules get me through the
common objects, and if I screw up a bit, I feel pretty confident that
most objects I deal with will implement the Finalize/Dispose pattern
properly so it won't really hurt too much.

There are things I can rail against if I choose (the component model was
a terrible idea, IMHO), but in general I think MS made the right
trade-off with the GC and Dispose.

[Scott M.]

Re: Dispose Again!

>> [I am not aware of any complete text that lists the do's and don'ts of[color=blue][color=green]
>> what
>> to dispose or not. Instead, I am aware that circumstance by
>> circumstance,
>> one can determine if a particular class should or shouldn't be disposed.][/color]
>
> Of course I can readily accept the fact that you do not know this
> information; however, you must accept the fact that someone else may know,
> or at least be aware of good resources for finding, this specific
> information.[/color]

That's true. As someone who has worked with .NET since early beta, my
answer was based on what I have seen, heard and read. I believe that answer
to be correct. The list you seek does not exist. Up to you to do what you
want with that information, but it IS my answer to the specific question you
asked.
[color=blue][color=green]
>> Ah but see, you didn't answer the question that "I was asking". See, I
>> didn't ask what you or other people eat, I asked for a complete list of
>> what is and isn't harmful to eat. So as soon as you get that list to me,
>> I'll get you the imaginary list you are looking for.[/color]
>
> Ah, now perhaps you understand my frustration with your "answers" to my
> question. Perhaps not.[/color]

Actually not since I did answer your direct question, you just don't wish to
acknowledge the answer. You, on the other hand, did not address my
question.
[color=blue]
> Like you, I didn't ask what you or other people Dispose, I asked for a
> complete list of what should and should not be Disposed.[/color]

You know, I'd like you to tell me where my answer to your question was what
I personally Dispose or don't Dispose because you keep saying that I've
avoided your direct question and I keep telling you that this is not the
case. You and I have had 2 conversations going in this thread (1 about your
question and one about "splitting hairs" which is slightly off-topic). I
honestly believe that you have taken my posts about one and applied them as
responses to the other.
[color=blue]
> Which should make a much, much shorter list than items that can be
> swallowed. After all, there are far more things that can be "swallowed"
> than there are built-in classes in the .NET Framework that expose a
> Dispose method; however, as you can see, your answers apply to this
> situation (and probably any other situation you could possibly think up),
> without losing any of their practical value.[/color]

The actual amount of items in the Framework are large enough and the
inheritance used to create them is intracate enough to make such a list an
improbability (if not an impossibility) which is the point of my analogy.
[color=blue]
> Now, if you want to get into more practical detail, we could look at all
> objects that expose a "Swallow" method. We can further refine the "list"
> to "you will learn what not to swallow by experience" (you will learn when
> to use Dispose by experience),[/color]

Who said "you will learn when to use Dispose by experience"? That's not
what I said. I said "circumstan ce by circumstance,
one can determine if a particular class should or shouldn't be disposed"
[color=blue]
>"you can teach yourself advanced Chemistry and Biology courses and perform
>chemical analysis on everything that has a Swallow method" (after all you
>can learn IL and use ILDASM and Object Browser to determine which objects
>to Dispose), you can follow the Manufacturer's Recommendations for
>Swallowing - assuming there are any, and make note of the exceptions. I
>can also tell you that it is correct to swallow chocolate milk and chicken
>casserole based on their Swallow interfaces. That's 2 down, how many to
>go?[/color]

Ah bravo! Now, you've finally got to the point. YES, what you have written
above IS the course one should take to know when to and when not to Dispose.
And so, the last thing I will say here (and leave you whatever last words
you like) is that with this last paragraph you have (wittingly or not and
like it or not) arrived at what I've been trying to tell you all along.
This is the answer to your question: there is no list! Use ILDASM, the
Object Browser, and whatever other tools available to investigate the
classes you work with and learn about them. Then, based on what you've
learned, you can make a much more informed decision about Dispose.

Good luck to you.

[Michael C#]

Re: Dispose Again!

At this point, it is probably best that we just agree to disagree and go our
separate ways. And here I suppose I get the last word in, and my last word
is: Thank you.

[Cor Ligthert]

Re: Dispose Again!

Jay,

I did first your routine and than the way I normal do it, I did not push the
F11 enough, than I would have seen it.

Thanks,

Cor

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> It would seem the next step would be to determine if the Dispose and
> Disposable types use unmanaged resources. Do you think there is a
> programmatic way to determine this?[/color]
Not really. However it might not provide you with what you want any way!

One Pattern/Recommendation (don't have the link handy, I can find it if you
like) is for your public class to define a private inner (nested) class that
contains (only manages) the unmanaged resource. Both classes Implement
IDisposable, however only the inner class implements Finalize. The public's
class Dispose delegates Dispose to an instance of the inner class.

This way only the small dedicated class is finalized, where as the bulkier
outer class will GC quicker. Normally this pattern would be used where you
have a class with a lot of managed instance fields, and only a single
unmanaged instance field.

Based on this thread I am revising my "rules" for when I don't call Dispose,
thus simplifying when I do call it. However! I have not flushed out the
entire list yet. When I get the list flushed out I will post it here. Note
it will be a list of rules similar to David's list (I believe it was
David's). Unfortunately it will not be a list by type! As I see little value
over time with a list by type! However if you accept the rules then creating
a list by type should be easy enough.

Hope this helps
Jay

"Michael C#" <xyz@abcdef.com > wrote in message
news:rH30e.5272 $dQ4.425@fe10.l ga...[color=blue]
> Now *that* is an excellent tool to discover a baseline. Thank you.
>
> IMHO, MS just needs to dedicate a person or two to documenting this and
> letting people know when and how to use their product; rather than leaving
> it to people to accidentally discover, or spend hours researching this
> when they could be doing far more productive things. It would seem the
> next step would be to determine if the Dispose and Disposable types use
> unmanaged resources. Do you think there is a programmatic way to
> determine this?
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:eZDpRqyLFH A.4092@tk2msftn gp13.phx.gbl...[color=green]
>> Michael,
>> Using the following in a VS.NET 2003 Windows Forms application I get:
>>
>> Assemblies: 5
>> Types: 3384
>> Disposable: 226
>> Dispose: 132
>>
>> There are significantly more then 5 assemblies in the entire .NET
>> Framework...
>>
>>
>> Const bindingAttr As BindingFlags = BindingFlags.De claredOnly _
>> Or BindingFlags.In stance Or BindingFlags.Ig noreCase _
>> Or BindingFlags.Pu blic Or BindingFlags.No nPublic
>> Dim disposable As Type = GetType(IDispos able)
>> Dim countAssemblies As Integer
>> Dim countTypes As Integer
>> Dim countDisposable As Integer
>> Dim countDispose As Integer
>> For Each a As [Assembly] In
>> AppDomain.Curre ntDomain.GetAss emblies()
>> countAssemblies += 1
>> For Each t As Type In a.GetTypes()
>> countTypes += 1
>> If disposable.IsAs signableFrom(t) Then
>> Debug.WriteLine (t.FullName, "IDisposabl e")
>> countDisposable += 1
>> End If
>> Try
>> If t.GetMethod("Di spose", bindingAttr) Is Nothing Then
>> ' No Dispose method.
>> Else
>> Debug.WriteLine (t.FullName, "Dispose")
>> countDispose += 1
>> End If
>> Catch ex As AmbiguousMatchE xception
>> Debug.WriteLine (t.FullName, "Dispose(s) ")
>> countDispose += 1
>> End Try
>> Next
>> Next
>> Debug.WriteLine (countAssemblie s, "Assemblies ")
>> Debug.WriteLine (countTypes, "Types")
>> Debug.WriteLine (countDisposabl e, "Disposable ")
>> Debug.WriteLine (countDispose, "Dispose")
>>
>> NOTE: The "t.GetMetho d" is an attempt to see if there is any Dispose
>> method declared on the type itself, as oppose to simply inheriting the
>> method from a base class...
>>
>> Hope this helps
>> Jay
>>
>> "Michael C#" <xyz@yomomma.co m> wrote in message
>> news:OuwLVJyLFH A.3832@TK2MSFTN GP12.phx.gbl...[color=darkred]
>>> Ahh, one down, 85 times X variations to go :) It seems like there are a
>>> lot more than 85 classes, however. But then again, I might be counting
>>> classes that are automatically excluded by virtue of not implementing
>>> Dispose() anyway.
>>>
>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in
>>> message news:OH1pXJxLFH A.1156@TK2MSFTN GP09.phx.gbl...
>>>> Michael,
>>>>> See, now we're making progress. Two down.
>>>> I would consider it one type, that is System.Windows. Forms.Form.
>>>>
>>>> Consider a variation of the sample:
>>>>
>>>> Dim dialog As Form
>>>>
>>>> dialog = New OptionsDialog
>>>> dialog.ShowDial og()
>>>> dialog.Dispose( )
>>>>
>>>> dialog = New OptionsDialog
>>>> dialog.Show()
>>>>
>>>> Its the exact same form, however based on how it is shown
>>>> (Form.ShowDialo g or Form.Show) changes if Dispose is needed or not...
>>>>
>>>>> Now how many classes does that leave? :)
>>>> The following page suggests there are 85 classes. I'm not sure if that
>>>> only includes types directly implementing IDisposable or if it includes
>>>> types that inherit IDisposable from a base class also.
>>>>
>>>> http://www.vbinfozine.com/a_disposable.shtml
>>>>
>>>>
>>>> I think the rule that is tripping people up (including the way I have
>>>> stated things) is when IDisposable is in a base class (such as
>>>> Component).
>>>>
>>>> Hope this helps
>>>> Jay
>>>>
>>>>
>>>> "Michael C#" <xyz@yomomma.co m> wrote in message
>>>> news:%23PIzINwL FHA.3760@TK2MSF TNGP12.phx.gbl. ..
>>>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in
>>>>> message news:%23GywAJwL FHA.3296@TK2MSF TNGP15.phx.gbl. ..
>>>>>> Consider objects that inherit from System.Windows. Forms.Form:
>>>>>>
>>>>>> Dim dialog As New OptionsDialog ' inherits Form
>>>>>> dialog.ShowDial og()
>>>>>> dialog.Dispose( )
>>>>>>
>>>>>> Dim child As New MidChildForm ' inherits Form
>>>>>> child.Show()
>>>>>
>>>>> See, now we're making progress. Two down. Now how many classes does
>>>>> that leave? :)
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Michael C#]

Re: Dispose Again!


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:uRR$hSAMFH A.3016@TK2MSFTN GP15.phx.gbl...[color=blue]
> Michael,[color=green]
>> It would seem the next step would be to determine if the Dispose and
>> Disposable types use unmanaged resources. Do you think there is a
>> programmatic way to determine this?[/color]
> Not really. However it might not provide you with what you want any way!
>
> One Pattern/Recommendation (don't have the link handy, I can find it if
> you like) is for your public class to define a private inner (nested)
> class that contains (only manages) the unmanaged resource. Both classes
> Implement IDisposable, however only the inner class implements Finalize.
> The public's class Dispose delegates Dispose to an instance of the inner
> class.
>
> This way only the small dedicated class is finalized, where as the bulkier
> outer class will GC quicker. Normally this pattern would be used where you
> have a class with a lot of managed instance fields, and only a single
> unmanaged instance field.[/color]

Ugh. So the unmanaged resources could be hidden from prying eyes anyway?
Too bad there's not a public read-only Boolean attribute you could check to
see if an object *needs* to be Disposed of or not. Something like
".DisposeRequir ed" or some such, or even a flag indicating that it uses (or
might use) unmanaged resources to give you a better idea up front that yes
this should be Disposed.

I really don't like this idea of writing sub-optimal code until I encounter
a problem and realize that 'hey I should have Disposed of that', then fixing
it after the fact with a "service pack"-type remedy. I am taking the plunge
and learning IL (it can't be harder than x86 Assembler can it?) I don't
mind learning something new, but I don't like feeling like I'm being forced
to learn it by weaknesses in my chosen platform - or even worse - by
weaknesses in the documentation of my chosen platform.
[color=blue]
> Based on this thread I am revising my "rules" for when I don't call
> Dispose, thus simplifying when I do call it. However! I have not flushed
> out the entire list yet. When I get the list flushed out I will post it
> here. Note it will be a list of rules similar to David's list (I believe
> it was David's). Unfortunately it will not be a list by type! As I see
> little value over time with a list by type! However if you accept the
> rules then creating a list by type should be easy enough.[/color]

I have no problem accepting the rules, if they help me narrow down the focus
of the problem. Throwing out things like "'Appropriately ' use Dispose" in
answer to the question of "How do I Appropriately use Dispose?" is basically
throwing the question back in the asker's face, and doesn't really narrow
the focus of the problem.

Thanks for your help on this!