I work on a huge project in C# .NET 4.0. There is a custom class inherited from System.Net.Sockets.SocketAsyncEventArgs class. Something like the following:
public class SocketTaskArgs : SocketAsyncEventArgs
{
public SocketTaskArgs()
{
Completed += someEventhHandler;
}
public void CleanUp()
{
Completed -= someEventhHandler;
}
/*
There is a lot of code here that is unimportant at the moment.
*/
}
So, I wanted to move the content of CleanUp() method to Dispose(bool) method.
As first, I checked the source code of the base class - SocketAsyncEventArgs (using Go To Definition so that I saw metadata as source). I found out, this class implements IDisposable interface. Nice, I just need to override the Dispose(bool) method, don't I? (See IDisposable Interface on MSDN, the "IDisposable and the inheritance hierarchy" section, for more details). Nothing new for me... Unfortunately, the SocketAsyncEventArgs class is implemented as following:
public class SocketAsyncEventArgs : EventArgs, IDisposable
{
public void Dispose();
//some other stuff here
}
That means, there is no way how to override Dispose(bool) method, as it's implemented as private instead of protected... What is the reason for this?
Next, I read about SocketAsyncEventArgs.Dispose() method on MSDN. The funny thing is that, it contains the following section:
Notes to Inheritors
Dispose can be called multiple times by other
objects. When overriding Dispose(Boolean), be careful not to reference
objects that have been previously disposed of in an earlier call to
Dispose. For more information about how to implement Dispose(Boolean),
see Implementing a Dispose Method.
Wait... what?
When overriding Dispose(Boolean), ...
How am I supposed to override Dispose(Boolean)?
What is the recommended way to implement IDisposable interface in this case?
There doesn't seem to be anything stopping you from implementing IDisposable on your child class, take this example:
public class DisposableParent : IDisposable
{
public void Dispose()
{
Console.WriteLine("The parent was disposed.");
}
}
public class DisposableChild : DisposableParent, IDisposable
{
public new void Dispose()
{
base.Dispose();
Console.WriteLine("The child was disposed.");
}
}
public class Program
{
public static void Main()
{
using (DisposableChild c = new DisposableChild()) { }
Console.ReadKey(true);
}
}
Gives the following output:
The parent was disposed.
The child was disposed.
The compiler warns about hiding the dispose of the parent class in the child, so using the new operator gets rid of that warning, just make sure to call the base class Dispose from the child class (and implement it the right way).
The dispose for the child would become something like:
public class DisposableChild : DisposableParent, IDisposable
{
private bool _disposed = false;
public new void Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
if (!_disposed)
{
base.Dispose();
Console.WriteLine("The child was disposed.");
_disposed = true;
}
}
}
}
And yes, this still works if you do something like:
using (DisposableParent p = new DisposableChild())
{
}
But something like this can break it:
public class Program
{
public static void Main()
{
DisposableChild c = new DisposableChild();
DisposeOfIt(c);
Console.ReadKey(true);
}
public static void DisposeOfIt(DisposableParent p)
{
p.Dispose();
}
}
Only prints out that the parent was disposed. So if you used this method you would have to be careful about controlling the lifetime of your objects.
Related
I am trying to implement the IDisposable pattern on a derived class, and it's not working as expecting to work,
Suppose I have two classes and I want to call the Dispose method of the derived class:
Below is the code of my base class
public class BaseClass : IDisposable
{
// To detect redundant calls
private bool _disposedValue;
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (!_disposedValue)
{
if (disposing)
{
// TODO: dispose managed state (managed objects)
}
// TODO: free unmanaged resources (unmanaged objects) and override finalizer
// TODO: set large fields to null
_disposedValue = true;
}
}
}
And I've something like this as a derived class
public class DerivedClass : BaseClass
{
// To detect redundant calls
private bool _disposedValue;
// Protected implementation of Dispose pattern.
protected override void Dispose(bool disposing)
{
if (!_disposedValue)
{
if (disposing)
{
}
_disposedValue = true;
}
// Call base class implementation.
base.Dispose(disposing);
}
}
And I've some wrapper class
public class WrapperClass : IDisposable
{
public ReadOnlyCollection<BaseClass> Items { get; set;}
// To detect redundant calls
private bool _disposedValue;
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (!_disposedValue)
{
if (disposing)
{
foreach (var item in Items)
{
item.Dispose();
}
}
_disposedValue = true;
}
}
}
My issue is in the wrapper class, it doesn't call the Dispose method of the DerivedClass, and it calls the Dispose method of the BaseClass instead.
Update
It's my bad, I forget to say that the collections of items were created by NSubstitute like below:
// Having this will not call the Dispose method of the derived class
Items = new ReadOnlyCollection<BaseClass>(new List<BaseClass>
{
Substitute.For<DerivedClass>()
})
// Having this will call the Dispose method of the derived class
Items = new ReadOnlyCollection<BaseClass>(new List<BaseClass>
{
new DerivedClass>()
})
The public implementation of the Dispose() pattern in the documentation is there as an example to handle every case and contingency. It's always "safe" to do the whole thing, but it's also true that most of the time you can skip most of the pattern.
Especially regarding finalizers: you should only need a finalizer if you are creating an original wrapper implementation for a brand new kind of unmanaged resource. Each unmanaged resource type only needs one finalizer, at the root of the IDisposable inheritance tree. And if you don't add a finalizer, you don't need to worry about GC.SuppressFinalize(). Remove that, and some other balls drop as well.
In short, we can reduce the pattern for your DerivedClass all the way down to this:
public class DerivedClass : BaseClass
{
}
This DerivedClass type still provides the Dispose() method and IDisposable implementation inherited from it's parent, and if it doesn't introduce any other unmanaged resources that's all it needs.
My issue is in the wrapper class, it doesn't call the Dispose method of the DerivedClass, and it calls the Dispose method of the BaseClass instead.
When the base.Dispose() calls Dispose(true) the method override in the derived class is executed, which in turn will call base. Dispose(true).
DerivedClass doesn't appear to override Dispose(). Consequently, the base class version is invoked.
Add a public void Dispose() method that calls your protected void Dispose(bool disposing) implementation in DerivedClass.
Given the following class which implements both Dispose and IDisposable.Dispose:
internal class DisposableClass : IDisposable
{
public void Dispose()
{
}
void IDisposable.Dispose()
{
}
}
When I make a call to DisposeableClass.Dispose (through an instance of the class), the public void Dispose is called:
DisposableClass newClass = new DisposableClass();
try
{
}
finally
{
newClass.Dispose();
}
If you change the try-finally to a using statement, IDisposable.Dispose is called.
using (DisposableClass newClass = new DisposableClass())
{
}
But NOT the IDisposable.Dispose which I defined.
The compiler translates the using-statement to ((IDisposable)newClass).Dispose(). The full methodname shows it to be from System.IDisposable.Dispose.
IL_0014: callvirt instance void [mscorlib]System.IDisposable::Dispose()
When will my custom implementation of IDisposable.Dispose be called?
Note that I am not using this actual implementation and I get that this should not be used. But I am still curious as to which implementation gets called when.
If I'd have a different implementation for each of the Dispose methods; which implementation would be called when?
Your approach to disposing is wrong. You should look at The Dispose Pattern to understand how to do this properly.
However... To answer your question how / why are they called...
Your public void Dispose() is being called when you say newClass.Dispose(); because it is the best "match" for what you have asked. By that (and without getting too complicated) it is because it is the highest in the hierarchy and therefore the one the compiler expects you to mean because it is the most specific. If you hadn't created your own it would have gone through hierarchy to find a Dispose method.
When you wrap with using the compiler produces code similar to this:
DisposableClass newClass = new DisposableClass();
try
{
}
finally
{
((IDisposable)newClass).Dispose();
}
This will therefore call the IDiposable version explicitly.
UPDATE
Full working sample below that will give this output:
Manually calling newClass.Dispose();
public void Dispose() being called.
Now wrapped in using...
void IDisposable.Dispose() being called.
Manually calling IDisposable.Dispose();
void IDisposable.Dispose() being called.
Full working code (paste this inside a console app and run):
using System;
namespace zPlayGround
{
class Program
{
static void Main()
{
Console.WriteLine("Manually calling newClass.Dispose();");
var newClass = new DisposableClass();
try
{
}
finally
{
newClass.Dispose();
}
Console.WriteLine("Now wrapped in using...");
using (var usingClass = new DisposableClass())
{
}
Console.WriteLine("Manually calling IDisposable.Dispose();");
var demoClass = new DisposableClass();
try
{
}
finally
{
((IDisposable)newClass).Dispose();
}
Console.ReadKey();
}
}
internal class DisposableClass : IDisposable
{
public void Dispose()
{
Console.WriteLine("public void Dispose() being called.\r\n");
}
void IDisposable.Dispose()
{
Console.WriteLine("void IDisposable.Dispose() being called.\r\n");
}
}
}
I've looked in SO about a question like this one, and even that I've found quite a few, any of those threw any light into this matter for me.
Let's assume I have this code:
public class SuperObject : IDisposable
{
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing) { }
}
Do I need the protected virtual void Dispose(bool) on SuperObject? Since there is really nothing to dispose there.
public interface ICustom : IDisposable { }
public class Custom : ICustom
{
public SuperObject Super { get; protected set; }
public Custom()
{
Super = new SuperObject();
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public virtual void Dispose(bool disposing)
{
if (!disposing) return;
if (Super != null)
Super.Dispose();
}
}
public class Foo
{
public Foo()
{
using (var c = new Custom())
{
//do magic with c
}
}
}
Now what happens if I want/need/try to use Custom on a class like System.Web.Mvc.Controller which already implements and has implemented IDisposable?
public class Moo : Controller
{
Custom c;
public Moo()
{
c = new Custom();
}
// Use c throughout this class
}
How to properly dispose c in Moo?
The normal approach is to apply the standard IDisposable implementation - HOWEVER this is really only necessary if your class or some class that derives from it will use UNmanaged resources - this case is infact VERY rare (and when this case does apply it is better to wrap the unmanaged resource in its own class that has a full standard IDisposable implementation).
So assuming you are not dealing with UNmanaged resources (raw file handles, globally alloced memeory etc) and are only dealing with members that are disposable (i.e that have managed resources and implement IDisposable) then you can safely get a way with a mimimal implimentation of IDispose - that is:
Just have a single void Dispose() method. In that method just call dispose on dispoable members and then Dispose on the base class if its disposable. If you have a class hierachy its ok to make this Dispose virtual. There is no need to have a Dispose(bool) method. Nor is there any need to check if the object is disposed - because all your doing is calling dipsose on other objects and those implementation will do that check.
If you don't like the mimimal appraoch then apply the standard full implimentation (but it is not strictly necessary). I.e either do a standard implimentation because your a stickler for following the recommended approach OR do a simple minimal (but correct) implementation - but don't do something in between (i.e not standard, not simple or not correct)!
See this question for more details: Minimal IDispose implimenation for managed resources only
So in your case the following is the mimimal implimentation:
public class SuperObject : IDisposable {
public void Dispose() {
// Dispose code...just call dispose on dispoable members.
// If there are none then no need to implement IDisposable!
}
}
public interface ICustom : IDisposable { }
public class Custom : ICustom {
public SuperObject Super { get; protected set; }
public Custom() {
Super = new SuperObject();
}
public void Dispose() {
if (Super != null)
Super.Dispose();
}
}
public class Moo : Controller {
Custom c;
public Moo() {
c = new Custom();
}
public Dispose() {
if (c!=null)
c.Dispose()
base.Dispose();
}
}
Note that if Super object does not have any disposable resources then there is no point in implementing IDisposable and having a Dispose method. If Customs only disposable object is SuperObject then the same applies there, and again the same logic rocks through to Moo. Finally then if all the above applies and there are no other disposable objects around all you need really need is:
public class Moo : Controller {
Custom c;
public Moo() {
c = new Custom();
}
public Dispose() {
base.Dispose();
}
}
How to properly dispose c in Moo?
public class Moo : Controller
{
Custom c;
public Moo()
{
c = new Custom();
}
// Use c throughout this class
protected override Dispose(bool disposing)
{
base.Dispose(disposing);
if (disposing)
c.Dispose()
}
}
And that also answers your first question, Controller needs to make its Dispose(bool) method protected virtual or the above would not be possible.
But a few notes:
you don't have any isDisposed logic. It is a good idea to do the disposing only once, and you may want to trap usage-after-dispose.
omitting destructors (finalizers) is in itself a good idea but you now have the extra constraint that no derived class should own an unmanaged resource.
I have written the following class:
public class CoupleFrames
{
public CoupleFrames(ColorImageFrame cif, Bitmap df)
{
this.colorFrame = cif;
this.desktopFrame = df;
}
public ColorImageFrame colorFrame;
public Bitmap desktopFrame;
}
Now I'm using the following code for disposing the variables.
CoupleFrames cf = new CoupleFrames(frame1, frame2);
// some code...
cf.colorFrame.Dispose();
cf.desktopFrame.Dispose();
I'm not sure that this is the correct way. Someone can suggest me the correct way for disposing the entire object?
I'm not sure that this is the correct way. Someone can suggest me the correct way for disposing the entire object?
Sure - you should make CoupleFrames implement IDisposable, and its Dispose method should dispose of the objects it "owns". For example:
public sealed class CoupleFrames : IDisposable
{
private readonly ColorImageFrame colorFrame;
private readonly Bitmap desktopFrame;
public CoupleFrames(ColorImageFrame cif, Bitmap df)
{
// TODO: Argument validation, unless it's valid for these parameters
// to be null, in which case the Dispose method would need to be careful.
this.colorFrame = cif;
this.desktopFrame = df;
}
public void Dispose()
{
colorFrame.Dispose();
desktopFrame.Dispose();
}
}
A few points to note:
You should make sure it's clear that the CoupleFrame really "owns" these constituent objects. Disposal relies on a clear ownership model
If CoupleFrame isn't sealed (and can't be) you may need to go into a more complicated pattern with virtual methods and finalizers. It can get very complicated, and you should read the advice given here by Joe Duffy et al. If your class is sealed, a lot of that complexity goes away
Public fields are generally a bad idea (in terms of encapsulation), which is why I've made them private here. I've also made them readonly, as if they can be changed later you need to think about whether changing them should dispose of the previously-referenced object etc.
By making CoupleFrame implement IDisposable, you're basically telling all clients that they should dispose of any instance they own. If you're not happy with imposing that burden, you need to rethink the design a bit.
I would implement the Dispose pattern
public class CoupleFrames : IDisposable
{
public CoupleFrames(ColorImageFrame cif, Bitmap df)
{
this.colorFrame = cif;
this.desktopFrame = df;
}
public ColorImageFrame colorFrame;
public Bitmap desktopFrame;
private bool disposed;
public void Dispose()
{
Dispose(true);
GC.SupressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposed)
{
return;
}
if (disposing)
{
colorFrame.Dispose();
desktopFrame.Dispose();
}
disposed = true;
}
}
You can use the IDisposable interface.
public class CoupleFrames : IDisposable
{
....
public void Dispose()
{
// Your disposing code here
}
~CoupleFrames()
{
Dispose();
}
}
You can use the destructor to call the Dispose method since the object can sometimes be deleted by the GC.
Make CoupleFrames Implement the Idisposable Interface.
public class CoupleFrames : IDisposable
{
public CoupleFrames(ColorImageFrame cif, Bitmap df)
{
this.colorFrame = cif;
this.desktopFrame = df;
}
public ColorImageFrame colorFrame;
public Bitmap desktopFrame;
public void Dispose()
{
cf.colorFrame.Dispose();
cf.desktopFrame.Dispose();
}
I have problem with increasing memory. I use MEF in caliburn.micro on creation new screen - WPF window.
View model of screen/view look like this:
[Export(typeof(IChatViewModel))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class ChatViewModel : Screen, IChatViewModel
{}
On creation I use ExportFactory, controler is here:
public interface IViewModelsControler
{
ExportLifetimeContext<IChatViewModel> CreatChatViewModel();
}
[Export(typeof(IViewModelsControler))]
public class ViewModelsControler : IViewModelsControler
{
[Import]
public ExportFactory<IChatViewModel> ChatViewFactory { get; set; }
public ExportLifetimeContext<IChatViewModel> CreatChatViewModel()
{
return ChatViewFactory.CreateExport();
}
}
I use ViewModelsControler class in ChatScreenManager class. This class Open/Remove chat screen.
Here is it:
[Export(typeof(IChatScreenManager))]
public class ChatScreenManager : IChatScreenManager
{
private IWindowManager _windowManager;
[Import]
public IViewModelsControler ViewModelControler { get; set; }
[ImportingConstructor]
public ChatScreenManager(IWindowManager windowManager)
{
_windowManager = windowManager;
ActiveChatScreens = new Dictionary<string, ExportLifetimeContext<IChatViewModel>>();
}
//store active screen
public Dictionary<string, ExportLifetimeContext<IChatViewModel>> ActiveChatScreens { get; set; }
public void OpenChatScreen(DetailData oponent, string avatarNick, BitmapImage avatarImage)
{
if (!ActiveChatScreens.ContainsKey(oponent.Info.Nick))
{
//create new chat screen with view model controler
ExportLifetimeContext<IChatViewModel> chatScreen = ViewModelControler.CreatChatViewModel();
//show
_windowManager.Show(chatScreen.Value);
//add ref to the dic
ActiveChatScreens.Add(oponent.Info.Nick, chatScreen);
}
}
public void RemoveChatScreen(string clossingScreen)
{
MessageBox.Show(GC.GetTotalMemory(true).ToString());
ActiveChatScreens[clossingScreen].Dispose();
ActiveChatScreens.Remove(clossingScreen);
GC.Collect();
GC.SuppressFinalize(this);
MessageBox.Show(GC.GetTotalMemory(true).ToString());
}
}
And my problem is:
I call OpneChatScreen method from ChatScreenManager it open new WPF window
Add reference on this window to the dictionary.
When I am closing window I call RemoveChatScreen.
In RemoveChaScreen:
I get total memory, for example is it 37,000K
Then I call Dipose method on ExportLifetimeContext chatScreen
Force GC
And get total memory, for example is it 39,000K
Memory usage is stil increasing. I hope if I call Dispose method on object ChatViewModel and also ChatView object these object are destroyed.
Do not force GC! Also, the Dispose() method should follow removal from your collection.
public void RemoveChatScreen(string closingScreen)
{
MessageBox.Show(GC.GetTotalMemory(true).ToString());
IChatViewModel chatWindow = ActiveChatScreens[closingScreen]
// remove from collection - GC may pass over object referenced in collection
// until next pass, or 3rd pass...who knows, it's indeterminate
ActiveChatScreens.Remove(closingScreen);
// all clean up should be performed within Dispose method
chatWindow.Dispose();
//GC.Collect();
//GC.SuppressFinalize(this);
MessageBox.Show(GC.GetTotalMemory(true).ToString());
}
Forcing garbage collection is not recommended. There are ways to work with GC, however, and that is typically done in the Dispose() method of the disposable class. Your derived ChatView object should be defined something like:
class ChatView : IChatViewModel, IDisposable
{ }
ChatView requires a Dispose() method be implemented. There is a pattern to follow (from MSDN) when creating disposable classes:
// Design pattern for a base class.
public class ChatView : IChatViewModel, IDisposable
{
private bool disposed = false;
//Implement IDisposable.
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Free other state (managed objects).
}
// Free your own state (unmanaged objects).
// Set large fields to null.
disposed = true;
}
}
// Use C# destructor syntax for finalization code.
~ChatView()
{
// Simply call Dispose(false).
Dispose (false);
}
}