dispose

Is there any sense to set custom object to null ( Nothing in VB.NET) in the Dispose() method? Could this prevent memory leaks or it's useless?! Let's consider two examples: public class Foo : IDisposable { private Bar bar; // standard custom .NET object public Foo(Bar bar) { this.bar = bar; } public void Dispose() { bar = null; // any sense? } } public class Foo : RichTextBox { // this could be also: GDI+, TCP socket, SQl Connection, other "heavy" object private Bitmap backImage; public Foo(Bitmap backImage) { this.backImage = backImage; } protected override void Dispose(bool disposing) { if

Is there a method, or some other light-weight way, to check if a reference is to a disposed object? P.S. - This is just a curiousity (sleep well, not in production code). Yes, I know I can catch the ObjectDisposedException upon trying to access a member of the object. It depends, there are IDisposable objects that allow to call the Dispose method as much as you want, and there are IDisposable objects that throw ObjectDisposedException . In such a case these objects must track the state (usually implemented with a private boolean field isDisposed ). No - default implementation of IDisposable

When I run code analysis on the following chunk of code I get this message: Object 'stream' can be disposed more than once in method 'upload.Page_Load(object, EventArgs)'. To avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object. using(var stream = File.Open(newFilename, FileMode.CreateNew)) using(var reader = new BinaryReader(file.InputStream)) using(var writer = new BinaryWriter(stream)) { var chunk = new byte[ChunkSize]; Int32 count; while((count = reader.Read(chunk, 0, ChunkSize)) > 0) { writer.Write(chunk, 0, count); } } I don't

Possible Duplicate: How does one tell if an IDisposable object reference is disposed? Is there a method to check if object has been disposed different then try { myObj.CallRandomMethod(); } catch (ObjectDisposedException e) { // now I know object has been disposed } In my case I'm using TcpClient class that has Close() method which disposes object and this can happen in piece of code I don't have control of. In this case I would like to have better solution then catching exception. Hans Passant A good way is to derive from TcpClient and override the Disposing(bool) method: class MyClient :

In one of the WCF tutorials, I saw the following sample code: Dim service as ...(a WCF service ) try .. service.close() catch ex as Exception() ... service.abort() end try Is this the correct way to ensure that resources (i.e. connections) are released even under error conditions? I've had good luck with this model: Dim service As New MyService() Dim closed As Boolean = False Try service.Open() If Not service.State = ServiceModel.CommunicationState.Opened Then ''Handle a not-opened state here End If service.MyMethod() service.Close() closed = true Catch ex As Exception ''Handle errors here

This was a telephone interview question I had: Is there a time when Dispose will not be called on an object who's scope is declared by a using block? My answer was no - even if an exception happens during the using block, Dispose will still be called. The interviewer disagreed and said if using is wrapped in a try - catch block then Dispose will not be called by the time you enter the catch block. This goes contrary to my understanding of the construct, and I haven't been able to find anything that backs up the interviewers point of view. Is he correct or might I have misunderstood the

It's recently been pointed out to me that various Linq extension methods (such as Where , Select , etc) return an IEnumerable<T> that also happens to be IDisposable . The following evaluates to True new int[2] {0,1}.Select(x => x*2) is IDisposable Do I need to dispose of the results of a Where expression? Whenever I call a method returning IEnumerable<T> , am I (potentially) accepting responsibility for calling dispose when I've finished with it? No, you don't need to worry about this. The fact that they return an IDisposable implementation is an implementation detail - it's because iterator