If you expect callers to only be able to interact with the interface, and never the implementation, then you want to have the interface extend IDisposable. If not, they’ll need to check if the value is IDisposable anyway to see if it needs to be disposed. If the object responsible for disposing of the object … Read more
There is no single answer, it depends on your scenario, and the key point is ownership of the disposable resource represented by the property, as Jon Skeet points out. It’s sometimes helpful to look at examples from the .NET Framework. Here are three examples that behave differently: Container always disposes. System.IO.StreamReader exposes a disposable property … Read more
When implementing the dispose pattern you might also add a finalizer to your class that calls Dispose(). This is to make sure that Dispose() always gets called, even if a client forgets to call it. To prevent the dispose method from running twice (in case the object already has been disposed) you add GC.SuppressFinalize(this);. The … Read more
If you access the AvailableWaitHandle property, then Yes, you must call Dispose() to cleanup unmanaged resources. If you do not access AvailableWaitHandle, then No, calling Dispose() won’t do anything important. SemaphoreSlim will create a ManualResetEvent on demand if you access the AvailableWaitHandle. This may be useful, for example if you need to wait on multiple … Read more
Calling the Dispose method is not required but you can still call it if you need for some reasons. Proof: HttpClient and lifetime management Disposal of the client isn’t required. Disposal cancels outgoing requests and guarantees the given HttpClient instance can’t be used after calling Dispose. IHttpClientFactory tracks and disposes resources used by HttpClient instances. … Read more
This is normally done if the class has a Close method that is the exact same as Dispose. The original Dispose is hidden in an explicit implementation so that the exact same method doesn’t have two names. It’s officially recommended here: Do implement a Close method for cleanup purposes if such terminology is standard, for … Read more
Dispose is called after the view is rendered, always. The view is rendered in the call to ActionResult.ExecuteResult. That’s called (indirectly) by ControllerActionInvoker.InvokeAction, which is in turn called by ControllerBase.ExecuteCore. Since the controller is in the call stack when the view is rendered, it cannot be disposed then.
The CLR documentation states that whoever creates a Disposable object is responsible for calling Dispose. In this case the object is created by Ninject. That means you should not call Dispose explicitly. Ninject disposes every Disposable object that has another scope other than InTransientScope as soon as the scope object to which the created object … Read more
So it seems like the calling code needs to know about and take ownership of the response message as well as the stream, or I leave the response message undisposed and let the finalizer deal with it. Neither option feels right. In this specific case, there are no finalizers. Neither HttpResponseMessage or HttpRequestMessage implement a … Read more
You don’t manually destroy .Net objects. That’s what being a managed environment is all about. In fact, if the object is actually reachable, meaning you have a reference you can use to tell the GC which object you want to destroy, collecting that object will be impossible. The GC will never collect any object that’s … Read more