dispose

Finalizer and IDisposable

梦想与她 提交于 2019-11-26 16:56:37
问题 Based on the documentation (MSDN: link), it is clear that one should use the IDisposable pattern when implementing a finalizer. But do you need to implement a finalizer if you implement IDisposable (so as to provide a deterministic way of disposing the object), and you dont have any unmanaged resources to clean up? As I see it, if the class has only managed resources and if you dont call Dispose, the managed resources will automatically get cleaned up by the GC and hence no need to implement

Who Disposes of an IDisposable public property?

微笑、不失礼 提交于 2019-11-26 16:39:46
问题 If I have a SomeDisposableObject class which implements IDisposable : class SomeDisposableObject : IDisposable { public void Dispose() { // Do some important disposal work. } } And I have another class called AContainer , which has an instance of SomeDisposableObject as a public property: class AContainer { SomeDisposableObject m_someObject = new SomeDisposableObject(); public SomeDisposableObject SomeObject { get { return m_someObject; } set { m_someObject = value; } } } Then FxCop will

Is it necessary to dispose System.Timers.Timer if you use one in your application?

∥☆過路亽.° 提交于 2019-11-26 16:12:15
问题 I am using System.Timers.Timer class in one of the classes in my application. I know that Timer class has Dispose method inherited from the parent Component class that implements IDisposable interface. Instances of the class below are created many times during my application lifecycle; each of them has an instance of Timer class that generates Elapsed events continuously during the class's lifecycle. Should I implement IDisposable interface in the class that uses Timer class to dispose the

Disposing WPF User Controls

被刻印的时光 ゝ 提交于 2019-11-26 16:01:02
I have created a custom WPF user control which is intended to be used by a third party. My control has a private member which is disposable, and I would like to ensure that its dispose method will always get called once the containing window/application is closed. However, UserControl is not disposable. I tried implementing the IDisposable interface and subscribing to the Unloaded event but neither get called when the host application closes. If at all possible, I don't want to rely on consumers of my control remembering to call a specific Dispose method. public partial class MyWpfControl :

Avoid calling Invoke when the control is disposed

五迷三道 提交于 2019-11-26 14:19:20
问题 I have the following code in my worker thread ( ImageListView below is derived from Control ): if (mImageListView != null && mImageListView.IsHandleCreated && !mImageListView.IsDisposed) { if (mImageListView.InvokeRequired) mImageListView.Invoke( new RefreshDelegateInternal(mImageListView.RefreshInternal)); else mImageListView.RefreshInternal(); } However, I get an ObjectDisposedException sometimes with the Invoke method above. It appears that the control can be disposed between the time I

using statement FileStream and / or StreamReader - Visual Studio 2012 Warnings

耗尽温柔 提交于 2019-11-26 13:48:36
问题 The new Visual Studio 2012 is complaining about a common code combination I have always used. I know it seems like overkill but I have done the following in my code 'just to be sure'. using (var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)) { using (var sr = new StreamReader(fs)) { // Code here } } Visual studio is 'warning' me that I am disposing of fs more than once. So my question is this, would the proper way to write this be: using (var fs = new

What happens if i return before the end of using statement? Will the dispose be called?

谁说胖子不能爱 提交于 2019-11-26 12:57:24
问题 I\'ve the following code using(MemoryStream ms = new MemoryStream()) { //code return 0; } The dispose() method is called at the end of using statement braces } right? Since I return before the end of the using statement, will the MemoryStream object be disposed properly? What happens here? 回答1: Yes, Dispose will be called. It's called as soon as the execution leaves the scope of the using block, regardless of what means it took to leave the block, be it the end of execution of the block, a

What is IDisposable for?

我的梦境 提交于 2019-11-26 12:46:05
问题 If .NET has garbage collection then why do you have to explicitly call IDisposable ? 回答1: Garbage collection is for memory. You need to dispose of non-memory resources - file handles, sockets, GDI+ handles, database connections etc. That's typically what underlies an IDisposable type, although the actual handle can be quite a long way down a chain of references. For example, you might Dispose an XmlWriter which disposes a StreamWriter it has a reference to, which disposes the FileStream it

What is the difference between using IDisposable vs a destructor in C#?

余生颓废 提交于 2019-11-26 12:45:29
When would I implement IDispose on a class as opposed to a destructor? I read this article , but I'm still missing the point. My assumption is that if I implement IDispose on an object, I can explicitly 'destruct' it as opposed to waiting for the garbage collector to do it. Is this correct? Does that mean I should always explicitly call Dispose on an object? What are some common examples of this? Marc Gravell A finalizer (aka destructor) is part of garbage collection (GC) - it is indeterminate when (or even if) this happens, as GC mainly happens as a result of memory pressure (i.e. need more

Do I need to dispose of a Task?

筅森魡賤 提交于 2019-11-26 11:37:32
问题 I am having fun working with System.Threading.Tasks . Many of the code samples I see, however, look something like so: Dim lcTask = Task.Factory.StartNew(Sub() DoSomeWork()) Dim lcTaskLong = Task.Factory.StartNew(Sub() DoSomeWork(), TaskCreationOptions.LongRunning) Task.WaitAll(lcTask, lcTaskLong) That\'s the extent of the sample. Tasks implement IDisposable , so obviously I\'m supposed to dispose of them, but what if I just want to \"Fire and Forget\"? If I don\'t dispose, will I leak