By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,133 Members | 1,092 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,133 IT Pros & Developers. It's quick & easy.

Disposing objects

P: n/a
I'm rather confused as to whether something should be disposed of, or not.
What is the general rule? How can you be sure of doing the right thing? I've
heard about disposing unmanaged resources but what is an unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure that
declares them?

Is there any way to check my program to see if I have something that needs
disposing and is still using resources?

-Jerry
Oct 4 '08 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Every object that implements an idisposable interface should be disposed of
i recomend you to write these objects in a using en using bloock

like this

Using Foo as new Foo.Lib

'''do your stuff

End using 'the end using will take care of disposing so no need to call it

also note that a declared variabel in a using block gets a block scope

Using Foo as new Foo.Lib
Dim Bla As string 'only accessible in the using block
'''do your stuff

End using

A unmanagaed resource is a resource that is not native to .Net but started
through interop , PInvoke etc etc
for instance API calls or COM objects

Object pointers that go out of scope will eventually be cleaned by the GC
however how and when this happens is a mystery that only the GC knows :-)

hth

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:p9******************************@posted.plusn et...
I'm rather confused as to whether something should be disposed of, or not.
What is the general rule? How can you be sure of doing the right thing?
I've heard about disposing unmanaged resources but what is an unmanaged
resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure
that declares them?

Is there any way to check my program to see if I have something that needs
disposing and is still using resources?

-Jerry

Oct 4 '08 #2

P: n/a
Michel,

Can you show me your latest program where you use the dispose method on
Label?

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:uD*************@TK2MSFTNGP06.phx.gbl...
Every object that implements an idisposable interface should be disposed
of
i recomend you to write these objects in a using en using bloock

like this

Using Foo as new Foo.Lib

'''do your stuff

End using 'the end using will take care of disposing so no need to call
it

also note that a declared variabel in a using block gets a block scope

Using Foo as new Foo.Lib
Dim Bla As string 'only accessible in the using block
'''do your stuff

End using

A unmanagaed resource is a resource that is not native to .Net but started
through interop , PInvoke etc etc
for instance API calls or COM objects

Object pointers that go out of scope will eventually be cleaned by the GC
however how and when this happens is a mystery that only the GC knows :-)

hth

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:p9******************************@posted.plusn et...
>I'm rather confused as to whether something should be disposed of, or
not. What is the general rule? How can you be sure of doing the right
thing? I've heard about disposing unmanaged resources but what is an
unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure
that declares them?

Is there any way to check my program to see if I have something that
needs disposing and is still using resources?

-Jerry

Oct 4 '08 #3

P: n/a
Aha ,, well you wanted more detailed info Cor ;-) ?

As we both know that calling Dispose in that case is not necesary as
Dispose is automatically called on all controls and components placed on
windows forms or user controls.

However in general the rule is

dispose everything that implements IDisposable
regards
Michel

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:74**********************************@microsof t.com...
Michel,

Can you show me your latest program where you use the dispose method on
Label?

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:uD*************@TK2MSFTNGP06.phx.gbl...
>Every object that implements an idisposable interface should be disposed
of
i recomend you to write these objects in a using en using bloock

like this

Using Foo as new Foo.Lib

'''do your stuff

End using 'the end using will take care of disposing so no need to call
it

also note that a declared variabel in a using block gets a block scope

Using Foo as new Foo.Lib
Dim Bla As string 'only accessible in the using block
'''do your stuff

End using

A unmanagaed resource is a resource that is not native to .Net but
started through interop , PInvoke etc etc
for instance API calls or COM objects

Object pointers that go out of scope will eventually be cleaned by the GC
however how and when this happens is a mystery that only the GC knows
:-)

hth

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:p9******************************@posted.plus net...
>>I'm rather confused as to whether something should be disposed of, or
not. What is the general rule? How can you be sure of doing the right
thing? I've heard about disposing unmanaged resources but what is an
unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure
that declares them?

Is there any way to check my program to see if I have something that
needs disposing and is still using resources?

-Jerry


Oct 4 '08 #4

P: n/a
Michel,
However in general the rule is
dispose everything that implements IDisposable
Who has given this general rule?
Or is it "yours" general rule, I don't that it is right to give things on
this board without telling that it is your general rule.

That the using has the dispose implemented is obvious, it is easier to
implement that, then spend time to find out if it should be there.

Cor

Oct 4 '08 #5

P: n/a
Jerry Spence1 wrote:
I'm rather confused as to whether something should be disposed of, or not.
What is the general rule? How can you be sure of doing the right thing? I've
heard about disposing unmanaged resources but what is an unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure that
declares them?

Is there any way to check my program to see if I have something that needs
disposing and is still using resources?

-Jerry
There are two ways that you can choose which objects to dispose:

1. If it has a Dispose method, call it.

2. Read the documentation and possibly other sources to find out if the
object really needs disposing. If you find reliable information that
says that it's not needed, you can skip the Dispose call.

Some people will say that the first is the only correct way, some will
say that the second is. Both works, and you can choose the one that is
suitable for your current situation. If you don't have time to waddle
around in the docs, just call Dispose and be done with it.

--
Göran Andersson
_____
http://www.guffa.com
Oct 4 '08 #6

P: n/a
Michel,

Let me say it in another way:

A lot of people write "You have to dispose everything in a class that
Implements IDisposable.

Which classes implements standard IDisposable? That are classes as forms as
they are made with the designer, as you wrote already by the label,
everything that is in the component is automaticly disposed.

People who write "everything that implements Idisopsable" mostly mean (or
it is understood), "Everything that has a dispose method".

However a dispose method says nothing, you can create it in every class
where that is not already there and which can be inherited, but by that does
it not implement Idisposable.

The standard dispose method (as it is inherited from component) is often
overridden to release unmanaged resources as we see by instance in most
Sharepoint classes. For sure I simple use everywhere in Sharepoint the
dispose method as there classes are often not much more than Com wrappers
and they have used Dispose for the releasing of that. So I agree that in
Sharepoint it is good practise to use everywhere the Dispose method before
something goes out of scope.

However in AdoNet by instance there is nothing where the dispose method
"should" be used. I could find also until now nowhere the dispose method in
a Linq class.

I have always a proplem when people in a kind of autheritair way write (I
don't know if this is English word, but you understand it), that "dispose
should be used wherever a class implements Idisopsable". They are in my idea
just parroting, something I was not expecting from you.

jmo

:-)

Cor


"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...
Aha ,, well you wanted more detailed info Cor ;-) ?

As we both know that calling Dispose in that case is not necesary as
Dispose is automatically called on all controls and components placed on
windows forms or user controls.

However in general the rule is

dispose everything that implements IDisposable
regards
Michel

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:74**********************************@microsof t.com...
>Michel,

Can you show me your latest program where you use the dispose method on
Label?

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:uD*************@TK2MSFTNGP06.phx.gbl...
>>Every object that implements an idisposable interface should be disposed
of
i recomend you to write these objects in a using en using bloock

like this

Using Foo as new Foo.Lib

'''do your stuff

End using 'the end using will take care of disposing so no need to call
it

also note that a declared variabel in a using block gets a block scope

Using Foo as new Foo.Lib
Dim Bla As string 'only accessible in the using block
'''do your stuff

End using

A unmanagaed resource is a resource that is not native to .Net but
started through interop , PInvoke etc etc
for instance API calls or COM objects

Object pointers that go out of scope will eventually be cleaned by the
GC however how and when this happens is a mystery that only the GC knows
:-)

hth

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:p9******************************@posted.plu snet...
I'm rather confused as to whether something should be disposed of, or
not. What is the general rule? How can you be sure of doing the right
thing? I've heard about disposing unmanaged resources but what is an
unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I
be sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure
that declares them?

Is there any way to check my program to see if I have something that
needs disposing and is still using resources?

-Jerry

Oct 4 '08 #7

P: n/a
IDisposable is a interface ( "Contract" ) , if the coder implemented
IDisposable you may asume that there is a reasson why he implemented this
"contract" in his code
so seeing from that light you "should" call the dispose method

http://msdn.microsoft.com/en-us/libr...e.dispose.aspx

page 201 of the VB.Net core reference

Because .Net objects don`t have real destructors , Well designed classes
should expose a method to let well behaved clients manually release any
resource such as files database connections and system objects as soon as
they do not need them any longer -- that is , just before setting the
reference to Nothing rather than waiting for for the subsequent garbage
collection .

Classes that want to provide this feature should implement IDisposable an
interface defined in the .Net Framework .........................

page 202

..Net programming guidelines dictate that the dispose method of an object
should invoke the dispose method of all the inner objects that the current
object owns and that are hidden from the client code ......

so yes it is an official guideline it is not MY guideline and to make it
more interesting it is a guideline for all .Net languages
And yes call me the dispose police but if i see code to objects in my
company written that implement idisposable without using blocks i convert
them to using blocks as i believe it is sloppy programming and for
readability of the code
if a contract is signed you must conform to that contract if you like it or
not in real life and in the programming world .

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:40**********************************@microsof t.com...
Michel,

Let me say it in another way:

A lot of people write "You have to dispose everything in a class that
Implements IDisposable.

Which classes implements standard IDisposable? That are classes as forms
as they are made with the designer, as you wrote already by the label,
everything that is in the component is automaticly disposed.

People who write "everything that implements Idisopsable" mostly mean (or
it is understood), "Everything that has a dispose method".

However a dispose method says nothing, you can create it in every class
where that is not already there and which can be inherited, but by that
does it not implement Idisposable.

The standard dispose method (as it is inherited from component) is often
overridden to release unmanaged resources as we see by instance in most
Sharepoint classes. For sure I simple use everywhere in Sharepoint the
dispose method as there classes are often not much more than Com wrappers
and they have used Dispose for the releasing of that. So I agree that in
Sharepoint it is good practise to use everywhere the Dispose method before
something goes out of scope.

However in AdoNet by instance there is nothing where the dispose method
"should" be used. I could find also until now nowhere the dispose method
in a Linq class.

I have always a proplem when people in a kind of autheritair way write (I
don't know if this is English word, but you understand it), that "dispose
should be used wherever a class implements Idisopsable". They are in my
idea just parroting, something I was not expecting from you.

jmo

:-)

Cor


"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...
>Aha ,, well you wanted more detailed info Cor ;-) ?

As we both know that calling Dispose in that case is not necesary as
Dispose is automatically called on all controls and components placed on
windows forms or user controls.

However in general the rule is

dispose everything that implements IDisposable
regards
Michel

"Cor Ligthert[MVP]" <no************@planet.nlschreef in bericht
news:74**********************************@microso ft.com...
>>Michel,

Can you show me your latest program where you use the dispose method on
Label?

Cor

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:uD*************@TK2MSFTNGP06.phx.gbl...
Every object that implements an idisposable interface should be
disposed of
i recomend you to write these objects in a using en using bloock

like this

Using Foo as new Foo.Lib

'''do your stuff

End using 'the end using will take care of disposing so no need to
call it

also note that a declared variabel in a using block gets a block scope

Using Foo as new Foo.Lib
Dim Bla As string 'only accessible in the using block
'''do your stuff

End using

A unmanagaed resource is a resource that is not native to .Net but
started through interop , PInvoke etc etc
for instance API calls or COM objects

Object pointers that go out of scope will eventually be cleaned by the
GC however how and when this happens is a mystery that only the GC
knows :-)

hth

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:p9******************************@posted.pl usnet...
I'm rather confused as to whether something should be disposed of, or
not. What is the general rule? How can you be sure of doing the right
thing? I've heard about disposing unmanaged resources but what is an
unmanaged resource?
>
Does everything need disposing?
>
I've been using Webrequest, Webresponse, Streamreaders etc. How can I
be sure of what needs disposing?
>
Do these get automatically get disposed of at the end of the procedure
that declares them?
>
Is there any way to check my program to see if I have something that
needs disposing and is still using resources?
>
-Jerry
>

Oct 4 '08 #8

P: n/a
The only thing i would like to add to this verry politicly correct answer of
Göran :-)
Failing to Dispose an object which implements IDisposable typically results
in the object going into the finalization queue (read Chapter 19 of Jeffrey
Richter's Applied Microsoft .NET Framework Programming for details). The
results of this is that an object's memory that might have otherwise been
freed in generation 01 be freed until a later generation collection. If
you're creating a lot of these objects, well, do the math."

So the worst thing that might happen is - that you should assume it could
cost you extra GC cycles if you don't ........
regards

And have a nice evening

Michel


"Göran Andersson" <gu***@guffa.comschreef in bericht
news:eX**************@TK2MSFTNGP03.phx.gbl...
Jerry Spence1 wrote:
>I'm rather confused as to whether something should be disposed of, or
not. What is the general rule? How can you be sure of doing the right
thing? I've heard about disposing unmanaged resources but what is an
unmanaged resource?

Does everything need disposing?

I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?

Do these get automatically get disposed of at the end of the procedure
that declares them?

Is there any way to check my program to see if I have something that
needs disposing and is still using resources?

-Jerry

There are two ways that you can choose which objects to dispose:

1. If it has a Dispose method, call it.

2. Read the documentation and possibly other sources to find out if the
object really needs disposing. If you find reliable information that says
that it's not needed, you can skip the Dispose call.

Some people will say that the first is the only correct way, some will say
that the second is. Both works, and you can choose the one that is
suitable for your current situation. If you don't have time to waddle
around in the docs, just call Dispose and be done with it.

--
Göran Andersson
_____
http://www.guffa.com
Oct 4 '08 #9

P: n/a
Michel Posseth wrote:
The only thing i would like to add to this verry politicly correct
answer of Göran :-)
Failing to Dispose an object which implements IDisposable typically
results in the object going into the finalization queue (read Chapter 19
of Jeffrey Richter's Applied Microsoft .NET Framework Programming for
details). The results of this is that an object's memory that might have
otherwise been freed in generation 01 be freed until a later generation
collection. If you're creating a lot of these objects, well, do the math."

So the worst thing that might happen is - that you should assume it
could cost you extra GC cycles if you don't ........
regards

And have a nice evening

Michel
Good point. However, it only applies if the class actually has a finalizer.

So, if the class has a Dispose method and a finalizer, you should always
call the Dispose method.
--
Göran Andersson
_____
http://www.guffa.com
Oct 5 '08 #10

P: n/a
On Oct 4, 3:31*am, "Cor Ligthert[MVP]" <notmyfirstn...@planet.nl>
wrote:
Michel,

Can you show me your latest program where you use the dispose method on
Label?

Cor
Controls are disposed automatically so it would not be difficult to
satisfy that request. In fact, you could probably just pull up a few
of your own.
Oct 6 '08 #11

P: n/a
On Oct 4, 1:23*pm, "Cor Ligthert[MVP]" <notmyfirstn...@planet.nl>
wrote:
Michel,

Let me say it in another way:

A lot of people write "You have to dispose everything in a class that
Implements IDisposable.
I am in that camp.
>
Which classes implements standard IDisposable? That are classes as forms as
they are made with the designer, as you wrote already by the label,
everything that is in the component is automaticly disposed.

People who write "everything that implements Idisopsable" *mostly mean (or
it is understood), "Everything that has a dispose method".

However a dispose method says nothing, you can create it in every class
where that is not already there and which can be inherited, but by that does
it not implement Idisposable.
When I'm talking about calling Dispose I'm specifically referring to
classes that implement IDisposable. I'm not aware of any classes that
have a Dispose method without implementing IDisposable; at least in
the BCL.
>
The standard dispose method (as it is inherited from component) is often
overridden to release unmanaged resources as we see by instance in most
Sharepoint classes. For sure I simple use everywhere in Sharepoint the
dispose method as there classes are often not much more than Com wrappers
and they have used Dispose for the releasing of that. So I agree that in
Sharepoint it is good practise to use everywhere the Dispose method before
something goes out of scope.
Just to clarify, the standard Dispose method is not marked as virtual
so it actually cannot be overriden. However, the protected
Dispose(Boolean) can be overriden.
However in AdoNet by instance there is nothing where the dispose method
"should" be used. I could find also until now nowhere the dispose method in
a Linq class.
Do you understand the consequences of not calling Dispose on say...a
SqlConnection instance?
I have always a proplem when people in a kind of *autheritair way write(I
don't know if this is English word, but you understand it), that "dispose
should be used wherever a class implements Idisopsable". They are in my idea
just parroting, something I was not expecting from you.
I happen to put a lot of stock in the MSDN documentation myself.
Oct 6 '08 #12

P: n/a
On Oct 4, 12:52*pm, Göran Andersson <gu...@guffa.comwrote:
Jerry Spence1 wrote:
I'm rather confused as to whether something should be disposed of, or not.
What is the general rule? How can you be sure of doing the right thing?I've
heard about disposing unmanaged resources but what is an unmanaged resource?
Does everything need disposing?
I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?
Do these get automatically get disposed of at the end of the procedure that
declares them?
Is there any way to check my program to see if I have something that needs
disposing and is still using resources?
-Jerry

There are two ways that you can choose which objects to dispose:

1. If it has a Dispose method, call it.

2. Read the documentation and possibly other sources to find out if the
object really needs disposing. If you find reliable information that
says that it's not needed, you can skip the Dispose call.

Some people will say that the first is the only correct way, some will
say that the second is. Both works, and you can choose the one that is
suitable for your current situation. If you don't have time to waddle
around in the docs, just call Dispose and be done with it.
I like to sum it up this way. When in doubt call Dispose. That
usually leads me to preferring #1.
Oct 6 '08 #13

P: n/a
>Do you understand the consequences of not calling Dispose on say...a
SqlConnection instance?

http://groups.google.com/group/micro...11c0671640ad38

Cor

Oct 6 '08 #14

P: n/a
On Oct 5, 10:59*pm, "Cor Ligthert[MVP]" <notmyfirstn...@planet.nl>
wrote:
Do you understand the consequences of not calling Dispose on say...a
SqlConnection instance?

http://groups.google.com/group/micro...framework.adon...

Cor
Yeah, Close and Dispose both close the connection. Everybody knows
that. So calling Close is the next best thing in lieu of calling
Dispose. That's great.

What other benefits do you miss out on by not calling Dispose? What
other unmanaged resources are left dangling until the GC runs the
finalizer? By analyzing with Reflector I can see that you'd only be
limited to keeping the object on the finalization queue...right now
anyway.

What would happen if Microsoft decided to tweak the implementation so
that Dispose did more things in a future version?

Now take a look at OleDbConnection using Reflector. Dispose really is
doing more than just closing the connection in that case. What about
a proprietary IDbConnection?

I'm currently working on a native .NET managed provider for a
proprietary database. I can tell you that Dispose is more aggressive
in releasing unmanaged resources than Close in my implementation.
Oct 6 '08 #15

P: n/a

"Brian Gideon" <br*********@yahoo.comwrote in message
news:80**********************************@f63g2000 hsf.googlegroups.com...
On Oct 4, 12:52 pm, Göran Andersson <gu...@guffa.comwrote:
Jerry Spence1 wrote:
I'm rather confused as to whether something should be disposed of, or
not.
What is the general rule? How can you be sure of doing the right thing?
I've
heard about disposing unmanaged resources but what is an unmanaged
resource?
Does everything need disposing?
I've been using Webrequest, Webresponse, Streamreaders etc. How can I be
sure of what needs disposing?
Do these get automatically get disposed of at the end of the procedure
that
declares them?
Is there any way to check my program to see if I have something that
needs
disposing and is still using resources?
-Jerry

There are two ways that you can choose which objects to dispose:

1. If it has a Dispose method, call it.

2. Read the documentation and possibly other sources to find out if the
object really needs disposing. If you find reliable information that
says that it's not needed, you can skip the Dispose call.

Some people will say that the first is the only correct way, some will
say that the second is. Both works, and you can choose the one that is
suitable for your current situation. If you don't have time to waddle
around in the docs, just call Dispose and be done with it.
I like to sum it up this way. When in doubt call Dispose. That
usually leads me to preferring #1.

===========================================
Gosh - I seem to have started a debate here! Not that I really understand
any of it. How can I tell if something implements IDisposable?

-Jerry
Oct 7 '08 #16

P: n/a

"Jerry Spence1" <12*@dfgh.comschreef in bericht
news:ZZ******************************@posted.plusn et...
>
"Brian Gideon" <br*********@yahoo.comwrote in message
news:80**********************************@f63g2000 hsf.googlegroups.com...
On Oct 4, 12:52 pm, Göran Andersson <gu...@guffa.comwrote:
>Jerry Spence1 wrote:
I'm rather confused as to whether something should be disposed of, or
not.
What is the general rule? How can you be sure of doing the right thing?
I've
heard about disposing unmanaged resources but what is an unmanaged
resource?
Does everything need disposing?
I've been using Webrequest, Webresponse, Streamreaders etc. How can I
be
sure of what needs disposing?
Do these get automatically get disposed of at the end of the procedure
that
declares them?
Is there any way to check my program to see if I have something that
needs
disposing and is still using resources?
-Jerry

There are two ways that you can choose which objects to dispose:

1. If it has a Dispose method, call it.

2. Read the documentation and possibly other sources to find out if the
object really needs disposing. If you find reliable information that
says that it's not needed, you can skip the Dispose call.

Some people will say that the first is the only correct way, some will
say that the second is. Both works, and you can choose the one that is
suitable for your current situation. If you don't have time to waddle
around in the docs, just call Dispose and be done with it.

I like to sum it up this way. When in doubt call Dispose. That
usually leads me to preferring #1.

===========================================
Gosh - I seem to have started a debate here! Not that I really understand
any of it. How can I tell if something implements IDisposable?

-Jerry
>How can I tell if something implements IDisposable?
i asume this was a question ?? :-)
As IDisposable is a interface you can easily see if it is implemented

If obj IsNot Nothing AndAlso TypeOf obj Is IDisposable Then
DirectCast(obj, IDisposable).Dispose()
End If

Balena published this generic method

Public Sub SetNothing(Of T)(ByRef obj As T)
' Dispose of the object if possible
If obj IsNot Nothing AndAlso TypeOf obj Is IDisposable Then
DirectCast(obj, IDisposable).Dispose()
End If
' Decrease the reference counter, if it's a COM object
If Marshal.IsComObject(obj) Then
Marshal.ReleaseComObject(obj)
End If
obj = Nothing
End Sub
HTH

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

Oct 7 '08 #17

P: n/a
On Oct 7, 12:34*am, "Jerry Spence1" <1...@dfgh.comwrote:
Gosh - I seem to have started a debate here! Not that I really understand
any of it. How can I tell if something *implements IDisposable?
There really isn't much of a debate. Cor is in the minority on this
issue and say that with all due respect because he is active in this
forum and has provided good advice on other issues in the past.
Oct 7 '08 #18

P: n/a
Raymond Chen recently posted a little story about the flaws of
programming to the implementation rather than the contract.

"Even if a function doesn't do anything, you still have to call it if
the documentation says so, because it might do something tomorrow"

http://blogs.msdn.com/oldnewthing/ar...5/8965129.aspx
Oct 7 '08 #19

P: n/a
On Oct 7, 12:11*pm, mark.tunnard.jack...@googlemail.com wrote:
Raymond Chen recently posted a little story about the flaws of
programming to the implementation rather than the contract.

"Even if a function doesn't do anything, you still have to call it if
the documentation says so, because it might do something tomorrow"

http://blogs.msdn.com/oldnewthing/ar...5/8965129.aspx
Exactly. Though I doubt it will make a difference to some people.
Oct 7 '08 #20

P: n/a
Jerry Spence1 wrote:
Gosh - I seem to have started a debate here! Not that I really understand
any of it. How can I tell if something implements IDisposable?
Check if it has a Dispose method.

I don't know of any method in the framework that has a Dispose method
without implementing the IDisposable interface.

--
Göran Andersson
_____
http://www.guffa.com
Oct 8 '08 #21

P: n/a
Gosh - I seem to have started a debate here!

Don't worry, its not the first time we've gone through this.

As a matter of fact, I stayed out of this one (until now) because I'm
tired of explaining why Cor is wrong in what he says. To sum things
up, you need to be calling Dispose, it causes the runtime to clean up
managed and unmanaged resources faster, and can prevent nasty side
effects depending on what the code is using (or will be using) the
Dispose method for.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
Oct 8 '08 #22

P: n/a
Failing to Dispose an object which implements IDisposable typically results
in the object going into the finalization queue (read Chapter 19 of Jeffrey
Richter's Applied Microsoft .NET Framework Programming for details). The
results of this is that an object's memory that might have otherwise been
freed in generation 01 be freed until a later generation collection. *If
you're creating a lot of these objects, well, do the math."

So the worst thing that might happen is - that *you should assume it could
cost you extra GC cycles if you don't *........
It should also be noted that the later generation GC cycles generally
occur less frequently and are more expensive in terms of process
time.

I have always thought it was ridiculous for developers to leave out
something in the application (be it using Dispose or writing unit
tests) just because they are too lazy to write the extra code to do
so. Leaving out two lines of code for IDisposable objects (Using...End
Using) can lead to one of the hardest to repro and debug problems -
memory leaks. And since we all (should) know that the true cost of the
application is in the maintenance, do your customers a favor and save
them money by writing proper code.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

Oct 8 '08 #23

P: n/a
Göran Andersson wrote:
Jerry Spence1 wrote:
Gosh - I seem to have started a debate here! Not that I really understand
any of it. How can I tell if something implements IDisposable?

Check if it has a Dispose method.

I don't know of any method in the framework that has a Dispose method
without implementing the IDisposable interface.
I'm sorry to disagree, but it seems to me that the *correct* way of
doing what the poster is asking is to explicity check if the object
implements IDisposable. And this is easier than checking (at run time)
if a given object has a Dispose method =)))

(unless, of course, you're saying "check if the object has a Dispose
method when you are typing in the IDE", which certainly is a way of
doing it...)

Now, to check if an object implements a given interface, the OP can
use the TryCast operator

<example>
Dim IDisp As IDisposable = TryCast(Obj, IDisposable)
If IDisp IsNot Nothing Then
'...
'... The object implements IDisposable
'...
End If
</example>

Another approach (if you actually don't want a reference to the
interface) is using TypeOf:

<example>
If TypeOf Obj Is IDisposable Then
'...
'... The object implements IDisposable
'...
End If
</example>

(Notice that in either case even if the object is Nothing TryCast and
TypeOf will do the Right Thing (TM))

Regards,

Branco.
Oct 10 '08 #24

P: n/a
On Oct 10, 8:37*am, Branco Medeiros <branco.medei...@gmail.comwrote:
(unless, of course, you're saying "check if the object has a Dispose
method when you are typing in the IDE", which certainly is a way of
doing it...)
Well, Goran can speak for himself, but I'm pretty sure that was what
he was talking about.

Regardless, you have to be careful when doing the check via
intellisense. If an interface is implemented explicitly then you
won't necessarily see its members. It's probably better to just check
for IDisposable in the Object Browser.

With that said, if IDisposable is implemented explicitly then usually
there is a corresponding public method on the class that releases the
resources. In the case of SqlDataReader, for instance, it has a Close
method without a public Dispose. That tells me that Close really does
have the same semantics as Dispose and that it really isn't necessary
to call Dispose (via the IDisposable interface). Despite that, I
still wrap the usage of SqlDataReader in a using block.
Oct 10 '08 #25

P: n/a
Brian,

Before you misunderstand my messages about dispose, this message from you I
find completely correct and I do it completely the same.

However, I don't like code that seems to do something, but does in fact
nothing.

It gives in my idea a pseudo idea of safety. Although it gives me as well
direct the idea that the creator of the program was probably a dilitant.

That the Using is invoking an empty dispose method does not make the code to
read dirty, while it has not much influence on the result.

Cor

"Brian Gideon" <br*********@yahoo.comschreef in bericht
news:43**********************************@s20g2000 prd.googlegroups.com...
On Oct 10, 8:37 am, Branco Medeiros <branco.medei...@gmail.comwrote:
(unless, of course, you're saying "check if the object has a Dispose
method when you are typing in the IDE", which certainly is a way of
doing it...)
Well, Goran can speak for himself, but I'm pretty sure that was what
he was talking about.

Regardless, you have to be careful when doing the check via
intellisense. If an interface is implemented explicitly then you
won't necessarily see its members. It's probably better to just check
for IDisposable in the Object Browser.

With that said, if IDisposable is implemented explicitly then usually
there is a corresponding public method on the class that releases the
resources. In the case of SqlDataReader, for instance, it has a Close
method without a public Dispose. That tells me that Close really does
have the same semantics as Dispose and that it really isn't necessary
to call Dispose (via the IDisposable interface). Despite that, I
still wrap the usage of SqlDataReader in a using block.

Oct 10 '08 #26

P: n/a
Branco Medeiros wrote:
Göran Andersson wrote:
>Check if it has a Dispose method.

I don't know of any method in the framework that has a Dispose method
without implementing the IDisposable interface.

I'm sorry to disagree, but it seems to me that the *correct* way of
doing what the poster is asking is to explicity check if the object
implements IDisposable. And this is easier than checking (at run time)
if a given object has a Dispose method =)))

(unless, of course, you're saying "check if the object has a Dispose
method when you are typing in the IDE", which certainly is a way of
doing it...)
Of course I am. Checking the type of the object at runtime is just a
waste of time. You should know when you write the code what class you
are using.

--
Göran Andersson
_____
http://www.guffa.com
Oct 13 '08 #27

P: n/a
"Göran Andersson" <gu***@guffa.comschrieb
Of course I am. Checking the type of the object at runtime is just a
waste of time. You should know when you write the code what class
you are using.
I agree. Unless you create objects by using reflection and don't know if
they also implement IDisposable.
Armin

Oct 13 '08 #28

P: n/a
Armin Zingler wrote:
"Göran Andersson" <gu***@guffa.comschrieb
>Of course I am. Checking the type of the object at runtime is just a
waste of time. You should know when you write the code what class
you are using.

I agree. Unless you create objects by using reflection and don't know if
they also implement IDisposable.

Armin
If one knows so little about the object one creates, one probably
shouldn't... :)

--
Göran Andersson
_____
http://www.guffa.com
Oct 15 '08 #29

P: n/a
Göran
>If one knows so little about the object one creates, one probably
shouldn't... :)

I use a method to check in one of my projects ( actually the one i posted )
, cause my project is a service wich is able to execute assemblys written by
other developers in my company , this service is written somewhere in early
2006 and in the end of 2007 upgraded to VB 2008 but weekly new assemblies
are beeing added that it must execute it is only aware of these assemblies
by a newly added database record .

What i try to say is that Armins comment can be pretty common in reall life
when using refelection eg a plugin architecture

regards
Michel

"Göran Andersson" <gu***@guffa.comschreef in bericht
news:eo**************@TK2MSFTNGP04.phx.gbl...
Armin Zingler wrote:
>"Göran Andersson" <gu***@guffa.comschrieb
>>Of course I am. Checking the type of the object at runtime is just a
waste of time. You should know when you write the code what class
you are using.

I agree. Unless you create objects by using reflection and don't know if
they also implement IDisposable.

Armin

If one knows so little about the object one creates, one probably
shouldn't... :)

--
Göran Andersson
_____
http://www.guffa.com


Oct 15 '08 #30

This discussion thread is closed

Replies have been disabled for this discussion.