Dispose and InitializeComponent

[=?Utf-8?B?RGF2ZSBIYXJyaXM=?=]

Theoretically, are there ever any cases or known defects where you should
have to do any of the following to objects created by the designer inside of
InitializeComponent()?

1 - call dispose() on an object
2 - set to null an object
3 - Manually tear down an event

I'm having a dickens of a time tracking down a memory bleed. I can reduce
the severity of the bleed by adding the above statements into the Dispose()
functions. I'm sure that by doing this I'm making sections of the graphed
memory unreachable so the GC reclaims it - just haven't figured out what
connection to the whole isn't getting severed yet.

I'm using the SciTech .NET memory profiler so I know the bleed is real.
Unfortunatlely it isn't following the reference links back to something
useful - they go back to Object [] which goes back to root

Thanks.

[Laura T.]

"Dave Harris" <Da********@discussions.microsoft.comha scritto nel
messaggio news:D3**********************************@microsof t.com...

Theoretically, are there ever any cases or known defects where you should
have to do any of the following to objects created by the designer inside
of
InitializeComponent()?

1 - call dispose() on an object
2 - set to null an object
3 - Manually tear down an event

None as far as I know.

I'm having a dickens of a time tracking down a memory bleed. I can reduce
the severity of the bleed by adding the above statements into the
Dispose()
functions. I'm sure that by doing this I'm making sections of the graphed
memory unreachable so the GC reclaims it - just haven't figured out what
connection to the whole isn't getting severed yet.

I'm using the SciTech .NET memory profiler so I know the bleed is real.
Unfortunatlely it isn't following the reference links back to something
useful - they go back to Object [] which goes back to root

Thanks.

Track'em down with windbg. It's harder but more "fun".
Here's a how to: http://blogs.msdn.com/ricom/archive/...10/279612.aspx