Typical usage is that Dispose() is overloaded, with a public, non-virtual Dispose() method, and a virtual, protected Dispose(bool). The public Dispose() method calls Dispose(true), and subclasses can use this protected virtual method to free up their own resorces, and call base.Dispose(true) for parent classes. If the class owning the public Dispose() method also implements a … Read more
The means of accomplishing this that I’ve seen require an extra method: public static void MyMethod() { using (var scope = MyScopedBehavior.Begin()) { //Do stuff with scope here scope.Complete(); // Tells the scope that it’s good } } By doing this, your scope object can track whether it’s disposing because of an error, or a … Read more
This is a false positive due to a minor bug in the rule itself. When trying to figure out if a class re-implements IDisposable (after figuring out that there’s a base class implementation that could be overridden), it only looks at whether the class’ interfaces include IDisposable. Unfortunately, the interface list that shows up in … Read more
I tend to use an integer rather than a boolean as your field for storing the disposed status, because then you can use the thread-safe Interlocked class to test if Dispose has already been called. Something like this: private int _disposeCount; public void Dispose() { if (Interlocked.Increment(ref _disposeCount) == 1) { // disposal code here … 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
There are only a few circumstances where Unity will dispose an instance. It is really unsupported. My solution was a custom extension to achieve this – http://www.neovolve.com/2010/06/18/unity-extension-for-disposing-build-trees-on-teardown/
FxCop might help (although it didn’t spot a test I just fired at it); but yes: you are meant to check. IDisposable is simply such an important part of the system that you need to get into this habit. Using intellisense to look for .D is a good start (though not perfect). However, it doesn’t … Read more
If you mean unmanaged objects then yes, you should be implementing it whenever you have one or more unmanaged resource you are handling in your class. You should also be using the pattern when you are possibly holding on to objects that are IDisposable themselves, and make sure to dispose of them when your class … Read more
You definitely do not want to call Dispose() on an object that was injected into your class. You can’t make the assumption that you are the only consumer. Your best bet is to wrap your unmanaged object in some managed interface: public class ManagedFileReader : IManagedFileReader { public string Read(string path) { using (StreamReader reader … Read more
You can extend IDisposable with method Complete and use pattern like that: using (MyWrapper wrapper = new MyWrapper()) { throw new Exception(“Bad error.”); wrapper.Complete(); } If an exception is thrown inside the using statement Complete will not be called before Dispose. If you want to know what exact exception is thrown, then subscribe on AppDomain.CurrentDomain.FirstChanceException … Read more