We Keep Coding

Is it really needed to implement dispose pattern for managed resources only

I've read carefully through this article and it seems to clearly state that the dispose pattern should be implemented in all cases of IDisposable implementation. I'm trying to understand why I need to implement the dispose pattern in cases when my class holds only managed resources (i.e. other IDisposable members or safe handles). Why cannot I just write
class Foo : IDisposable
{
IDisposable boo;
void Dispose()
{
boo?.Dispose();
}
}
If it's definitely known that there are no unmanaged resources and there is no point to call Dispose method from finalizer as managed resources aren't being freed from finalizer?
Update: In order to add some clarity. The discussion seems to come down to the question whether it's needed to implement the dispose pattern for every base public non-sealed class which implements IDisposable or not. I however cannot find potential problems with hierarchy when a base class without unmanaged resources doesn't use dispose pattern while child classes which have unmanaged resources do use this pattern:
class Foo : IDisposable
{
IDisposable boo;
public virtual void Dispose()
{
boo?.Dispose();
}
}
// child class which holds umanaged resources and implements dispose pattern
class Bar : Foo
{
bool disposed;
IntPtr unmanagedResource = IntPtr.Zero;
~Bar()
{
Dispose(false);
}
public override void Dispose()
{
base.Dispose();
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposed)
return;
if (disposing)
{
// Free any other managed objects here.
//
}
// close handle
disposed = true;
}
}
// another child class which doesn't hold unmanaged resources and merely uses Dispose
class Far : Foo
{
private IDisposable anotherDisposable;
public override void Dispose()
{
base.Dispose();
anotherDisposable?.Dispose();
}
}
Even more, for me it looks as better separation of concerns when implementations are responsible only for those things which they are aware of.

This
private class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
Is perfectly fine. As is
public sealed class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
What could go wrong if I have public not sealed base class implemented as above with virtual Dispose method ?
From the docs:
Because the order in which the garbage collector destroys managed
objects during finalization is not defined, calling this Dispose
overload with a value of false prevents the finalizer from trying to
release managed resources that may have already been reclaimed.
Accessing a managed object that has already been reclaimed, or accessing its properties after it's been Disposed (perhaps by another finalizer) will cause an Exception to be raised in the Finalizer, which is bad:
If Finalize or an override of Finalize throws an exception, and the
runtime is not hosted by an application that overrides the default
policy, the runtime terminates the process and no active try/finally
blocks or finalizers are executed. This behavior ensures process
integrity if the finalizer cannot free or destroy resources.
So if you had:
public class Foo : IDisposable
{
IDisposable boo;
public virtual void Dispose()
{
boo?.Dispose();
}
}
public class Bar : Foo
{
IntPtr unmanagedResource = IntPtr.Zero;
~Bar()
{
this.Dispose();
}
public override void Dispose()
{
CloseHandle(unmanagedResource);
base.Dispose();
}
void CloseHandle(IntPtr ptr)
{
//whatever
}
}
~Bar -> Bar.Dispose() -> base.Dispose() -> boo.Dispose() But boo may have been reclaimed by the GC.

I haven't seen this particular usage of Dispose mentioned yet, so I thought I'd point out a common source of memory leaks when not using the dispose pattern.
Visual Studio 2017 actually complains about this via static code analysis that I should "implement the dispose pattern". Do note I'm using SonarQube and SolarLint, and I don't believe Visual Studio will catch this alone. FxCop (another static code analysis tool) likely will, although I didn't test that.
I note the below code to showcase the dispose pattern is also there to protect against something like this, which has no unmanaged resources:
public class Foo : IDisposable
{
IDisposable boo;
public void Dispose()
{
boo?.Dispose();
}
}
public class Bar : Foo
{
//Memory leak possible here
public event EventHandler SomeEvent;
//Also bad code, but will compile
public void Dispose()
{
someEvent = null;
//Still bad code even with this line
base.Dispose();
}
}
The above illustrates very bad code. Don't do this. Why is this horrific code? That's because of this:
Foo foo = new Bar();
//Does NOT call Bar.Dispose()
foo.Dispose();
Let's assume this horrific code was exposed in our public API. Consider the above classes used by consumers of it:
public sealed class UsesFoo : IDisposable
{
public Foo MyFoo { get; }
public UsesFoo(Foo foo)
{
MyFoo = foo;
}
public void Dispose()
{
MyFoo?.Dispose();
}
}
public static class UsesFooFactory
{
public static UsesFoo Create()
{
var bar = new Bar();
bar.SomeEvent += Bar_SomeEvent;
return new UsesFoo(bar);
}
private static void Bar_SomeEvent(object sender, EventArgs e)
{
//Do stuff
}
}
Are the consumers perfect? No.... UsesFooFactory should probably also unsubscribe from the event. But it does highlight a common scenario where an event subscriber outlives the publisher.
I've seen events cause countless memory leaks. Especially in very large or extreme high performance codebases.
I can also hardly count how many times I've seen objects live long past their time of disposal. This is a very common way many profilers find memory leaks (disposed objects still held onto by a GC Root of some kind).
Again, overly simplified example and horrible code. But it's really never good practice to call Dispose on an object and not expect it to dispose the entire object, whether it has been derived from a million times or not.
Edit
Please note this answer is intentionally only addressing managed resources, showcasing that the dispose pattern is useful in this scenario as well. This purposefully does not address the use case for unmanaged resources as I felt there was a lack of focus on managed only uses. And there are many other good answers on here that talk about that.
I will, however, note a few quick things that are important when it comes to unmanaged resources. The above code might not address unmanaged resources, but I want to make clear it does not contradict how they should be handled.
It's extremely important to use finalizers when your class is responsible for unmanaged resources. Briefly, finalizers are automatically called by the Garbage Collector. So it gives you a reasonable guarantee that it always gets called at some point in time. It's not bulletproof, but a far cry from hoping user code calls Dispose.
This guarantee is not true of Dispose. An object can be reclaimed by the GC without Dispose ever being called. That's the key reason finalizers are used for unmanaged resources. The GC itself only handles managed resources.
But I will also note it's equally important finalizers should not be used to clean up managed resources. There are countless reasons why (it's the GC's job to do this after all) but one of the largest drawbacks to using finalizers is delaying garbage collection on an object.
The GC, seeing an object is free to reclaim but has a finalizer, will delay the collection by placing the object in the finalizer queue. This adds significant unnecessary lifetime to an object, plus more pressure on the GC.
Finally I'll note that finalizers are non-deterministic for this reason, despite having similar syntax to something like a destructor in C++. They are very different beasts. You should never rely upon a finalizer to clean up unmanaged resources at a specific point in time.

You probably got it wrong. You don't need to implement finilizer if you don't have unmanaged resources. You can check it by using automatic pattern implementation in Visual Studio (it will even generate the comments saying that you should uncomment the finalizer ONLY if you use unmanaged resources).
The dispose pattern is used only for objects that access unmanaged resources.
If you design a base class and some of the inheriting classes access unmanaged resources, the inheriting classes will deal with it themselves by overriding Dispose(bool) and defining the finalizer.
It's explained in this article, all finalizers will be called anyway if not suppressed. And if suppressed everything would have been released by the chain of Diapose(true) calls in the first place.

If Dispose() is implemented using a public virtual method, derived classes that expect to override that method can do so and all will be well. If, however, anything on the inheritance chain implements IDisposable.Dispose() via means other than overriding the public virtual Dispose() method, that can make it impossible for a sub-derived class to implement its own IDisposable.Dispose() while still being able to access the parent implementation.
The Dispose(bool) pattern can be used regardless of whether or not there is a public Dispose() method, and thus avoids the need to have separate patterns for the cases where a class does or does not expose a public Dispose() method. The GC.SuppressFinalize(this) could generally be replaced by a GC.KeepAlive(this), but for classes without finalizers the cost is about the same. In the absence of that call, the finalizers for any objects to which a class holds a reference could get triggered while the class' own Dispose method is running. Not a likely scenario, nor one that would usually cause problems even if it occurs, but passing this to GC.KeepAlive(Object) or GC.SuppressFinalize(Object) makes such quirky situations impossible.

Should I Treat Entity Framework as an Unmanaged Resource?

I am working with a class that uses a reference to EF in its constructor.
I have implemented IDisposable, but I'm not sure if I need a destructor because I'm not certain I can classify EF as an unmanaged resource.
If EF is a managed resource, then I don't need a destructor, so I think this is a proper example:
public ExampleClass : IDisposable
{
public ExampleClass(string connectionStringName, ILogger log)
{
//...
Db = new Entities(connectionStringName);
}
private bool _isDisposed;
public void Dispose()
{
if (_isDisposed) return;
Db.Dispose();
_isDisposed= true;
}
}
If EF is unmanaged, then I'll go with this:
public ExampleClass : IDisposable
{
public ExampleClass(string connectionStringName, ILogger log)
{
//...
Db = new Entities(connectionStringName);
}
public void Dispose()
{
Dispose(true);
}
~ExampleClass()
{
Dispose(false);
}
private bool _isDisposed;
protected virtual void Dispose(bool disposing)
{
if (_isDisposed) return;
// Dispose of managed resources
if (disposing)
{
// Dispose of managed resources; assumption here that EF is unmanaged.
}
// Dispose of unmanaged resources
Db.Dispose();
_isDisposed = true;
//freed, so no destructor necessary.
GC.SuppressFinalize(this);
}
}
Which one is it?

You would never want to use a finalizer (destructor) in this case.
Whether DbContext contains unmanaged resources or not, and even whether it responsibly frees those unmanaged resources or not, is not relevant to whether you can try to invoke DbContext.Dispose() from a finalizer.
The fact is that, any time you have a managed object (which an instance of DbContext is), it is never safe to attempt to invoke any method on that instance. The reason is that, by the time the finalizer is invoked, the DbContext object may have already been GC-collected and no longer exist. If that were to happen, you would get a NullReferenceException when attempting to call Db.Dispose(). Or, if you're lucky, and Db is still "alive", the exception can also be thrown from within the DbContext.Dispose() method if it has dependencies on other objects that have since been finalized and collected.
As this "Dispose Pattern" MSDN article says:
X DO NOT access any finalizable objects in the finalizer code path, because there is significant risk that they will have already been finalized.
For example, a finalizable object A that has a reference to another finalizable object B cannot reliably use B in A’s finalizer, or vice versa. Finalizers are called in a random order (short of a weak ordering guarantee for critical finalization).
Also, note the following from Eric Lippert's When everything you know is wrong, part two:
Myth: Finalizers run in a predictable order
Suppose we have a tree of objects, all finalizable, and all on the finalizer queue. There is no requirement whatsoever that the tree be finalized from the root to the leaves, from the leaves to the root, or any other order.
Myth: An object being finalized can safely access another object.
This myth follows directly from the previous. If you have a tree of objects and you are finalizing the root, then the children are still alive — because the root is alive, because it is on the finalization queue, and so the children have a living reference — but the children may have already been finalized, and are in no particularly good state to have their methods or data accessed.
Something else to consider: what are you trying to dispose? Is your concern making sure that database connections are closed in a timely fashion? If so, then you'll be interested in what the EF documentation has to say about this:
By default, the context manages connections to the database. The context opens and closes connections as needed. For example, the context opens a connection to execute a query, and then closes the connection when all the result sets have been processed.
What this means is that, by default, connections don't need DbContext.Dispose() to be called to be closed in a timely fashion. They are opened and closed (from a connection pool) as queries are executed. So, though it's still a very good idea to make sure you always call DbContext.Dispose() explicitly, it's useful to know that, if you don't do it or forget for some reason, by default, this is not causing some kind of connection leak.
And finally, one last thing you may want to keep in mind, is that with the code you posted that doesn't have the finalizer, because you instantiate the DbContext inside the constructor of another class, it is actually possible that the DbContext.Dispose() method won't always get called. It's good to be aware of this special case so you are not caught with your pants down.
For instance, suppose I adjust your code ever so slightly to allow for an exception to be thrown after the line in the constructor that instantiates the DbContext:
public ExampleClass : IDisposable
{
public ExampleClass(string connectionStringName, ILogger log)
{
//...
Db = new Entities(connectionStringName);
// let's pretend I have some code that can throw an exception here.
throw new Exception("something went wrong AFTER constructing Db");
}
private bool _isDisposed;
public void Dispose()
{
if (_isDisposed) return;
Db.Dispose();
_isDisposed= true;
}
}
And let's say your class is used like this:
using (var example = new ExampleClass("connString", log))
{
// ...
}
Even though this appears to be a perfectly safe and clean design, because an exception is thrown inside the constructor of ExampleClass after a new instance of DbContext has already been created, ExampleClass.Dispose() is never invoked, and by extension, DbContext.Dispose() is never invoked either on the newly created instance.
You can read more about this unfortunate situation here.
To ensure that the DbContext's Dispose() method is always invoked, no matter what happens inside the ExampleClass constructor, you would have to modify the ExampleClass class to something like this:
public ExampleClass : IDisposable
{
public ExampleClass(string connectionStringName, ILogger log)
{
bool ok = false;
try
{
//...
Db = new Entities(connectionStringName);
// let's pretend I have some code that can throw an exception here.
throw new Exception("something went wrong AFTER constructing Db");
ok = true;
}
finally
{
if (!ok)
{
if (Db != null)
{
Db.Dispose();
}
}
}
}
private bool _isDisposed;
public void Dispose()
{
if (_isDisposed) return;
Db.Dispose();
_isDisposed= true;
}
}
But the above is really only a concern if the constructor is doing more than just creating an instance of a DbContext.

C# provides garbage collection and thus does not need an explicit destructor. If you do control an unmanaged resource, however, you will need to explicitly free that resource when you are done with it. Implicit control over this resource is provided with a Finalize( ) method (called a finalizer), which will be called by the garbage collector when your object is destroyed.
https://www.oreilly.com/library/view/programming-c/0596001177/ch04s04.html

C# disposable objects

Are there some advices about how I should deal with the IDisposable object sequences?
For example, I have a method that builds a IEnumerable<System.Drawing.Image> sequence and
at some point I would need to dispose that objects manually, because otherwise this might lead to some leaks.
Now, is there a way to bind the Dispose() call to garbage collector actions, because I want these objects disposed right in the moment they are no longer accessible from other code parts?
**Or maybe you could advice me some other approach? **
Generally, this seems to be the same problem as it comes, for example, in unmanaged C++ without shared pointers, where you can have a method:
SomeObject* AllocateAndConstruct();
and then you can't be sure when to dispose it, if you don't use code contracts or don't state something in the comments.
I guess the situation with disposable objects is pretty the same, but I hope there is an appropriate solution for this.

(from the question)
Now, is there a way to bind the
Dispose() call to garbage collector
actions, because I want these objects
disposed right in the moment they are
no longer accessible from other code
parts?
GC doesn't happen immediately when your object goes out of scope / reach; it is non-deterministic. By the time GC sees it, there is no point doing anything else (that isn't already handled by the finalizer), as it is too late.
The trick, then, is to know when you are done with it, and call Dispose() yourself. In many cases using achieves this. For example you could write a class that implements IDisposable and encapsulates a set of Images - and wrap your use of that encapsulating object with using. The Dispose() on the wrapper could Dispose() all the images held.
i.e.
using(var imageWrapper = GetImages()) {
foreach(var image in imageWrapper) {
...
}
// etc
} // assume imageWrapper is something you write, which disposes the child items
however, this is a bit trickier if you are displaying the data on the UI. There is no shortcut there; you will have to track when you are done with each image, or accept non-deterministic finalization.

If you want to determiniscally dispose of the objects in the collection, you should call Dispose on each:
myImages.ToList().ForEach(image => image.Dispose());
If you don't do this, and if your objects become unreachable, the GC will eventually run and release them.
Now, if you don't want to manually code the Dispose calls, you can create a wrapper class that implements IDisposable and use it through a using statement:
using (myImages.AsDisposable()) {
// ... process the images
}
This is the needed "infrastructure":
public class DisposableCollectionWrapper<D> : IDisposable
where D : IDisposable {
private readonly IEnumerable<D> _disposables;
public DisposableCollectionWrapper(IEnumerable<D> disposables) {
_disposables = disposables;
}
public void Dispose() {
if (_disposables == null) return;
foreach (var disposable in _disposables) {
disposable.Dispose();
}
}
}
public static class CollectionExtensions {
public static IDisposable AsDisposable<D>(this IEnumerable<D> self)
where D : IDisposable {
return new DisposableCollectionWrapper<D>(self);
}
}
Also notice that this is not the same as the situation you described with C++. In C++, if you don't delete your object, you have a genuine memory leak. In C#, if you don't dispose of your object, the garbage collector will eventually run and clean it up.

You should design your system in a way that you know when the resources are no longer needed. In the worst case, they'll be eventually disposed when the garbage collector gets to it, but the point of IDisposable is that you can release important resources earlier.
This "earlier" is up to you to define, for example, you can release them when the window that's using them closes, or when your unit of work finishes doing whatever operations on them. But at some point, some object should "own" these resources, and therefore should know when they're no longer needed.

You can use the 'using' block, to make sure, the IDisposable is disposed as soon the block is left. The compiler does encapsulate such blocks into try - finally statements in order to make sure, Dispose is called in any case when leaving the block.
By using a finalizer, one can make the GC call the Dispose method for those objects which where "missed" somehow. However, implementing a finalizer is more expensive and decreases the garbage collection efficiency - and possibly the overall performance of your application. So if any possible, you should try to make sure to dispose your IDisposables on your own; deterministically:
public class Context : IDisposable {
List<IDisposable> m_disposable = new List<IDisposable>();
public void AddDisposable(IDisposable disposable) {
m_disposable.Add(disposable);
}
public void Dispose() {
foreach (IDisposable disp in m_disposable)
disp.Dispose();
}
// the Context class is used that way:
static void Main(string[] args) {
using (Context context = new Context()) {
// create your images here, add each to the context
context.AddDisposable(image);
// add more objects here
} // <- leaving the scope will dispose the context
}
}
By using some clever design, the process of adding objects to the context may can get even more easier. One might give the context to the creation method or publish it via a static singleton. That way, it would be available for child method scopes as well - without having to pass a reference to the contex around. By utilizing that scheme it is even possible, to simulate an artificial destructor functionality like f.e. known from C++.

The neat method would be to create your own generic collection class that implements IDisposable. When this collection class is Disposed() ask for each element if it implements IDisposed, and if so Dispose it.
Example (look elsewhere if you don't know about the IDisposable pattern)
public class MyDisposableList<T> : List<T> : IDisposable
{
private bool disposed = false;
~MyDisposableList()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
}
protected void Dispose(bool disposing)
{
if (!disposed)
{
foreach (T myT in this)
{
IDisposable myDisposableT = myT as IDisposable;
if (myDisposableT != null)
{
myDisposableT.Dispose();
}
myT = null;
}
this.Clear();
this.TrimExcess();
disposed = true;
}
}
...
}
usage:
using (MyDisposableList<System.Drawing.Bitmap> myList = new ...)
{
// add bitmaps to the list (bitmaps are IDisposable)
// use the elements in the list
}
The end of the using statement automatically Disposes myList, and thus all bitMaps in myList
By the way: if you loaded the bitmap from a file and you forgot to Dispose() the bitmap you don't know when you can delete that file.

You can call GC.Collect() if you really was to dispose those objects right away but to my understanding it is up to the GC to decide whether to collect the memory.
This in turn will call the Finalize() method for each object that should be released.
Note that if the collection goes out of scope the GC will eventually collect the memory used by the images.
You can also use the using construct if you use a collection that implements IDisposeable. That will guarantee that the objects will be disposed exactly when the collection goes out of scope (or nearly after the end of the scope).

Is this a legitimate alternative to the "traditional" dispose pattern for class hierarchies?

I am not a fan of boilerplate code: copy-paste reuse is potentially error-prone. Even if you use code snippets or smart templates, there is no guarantee the other developer did, which means there's no guarantee they did it right. And, if you have to see the code, you have to understand it and/or maintain it.
What I want to know from the community is: is my implementation of IDispose for a class hierarchy a legitimate alternative to the "traditional" dispose pattern? By legitimate, I mean correct, reasonably well performing, robust, and maintainable.
I am ok with this alternative being plain wrong, but if it is, I'd like to know why.
This implementation assumes you have full control over the class hierarchy; if you don't you'll probably have to resort back to boilerplate code. The calls to Add*() would typically be made in the constructor.
public abstract class DisposableObject : IDisposable
{
protected DisposableObject()
{}
protected DisposableObject(Action managedDisposer)
{
AddDisposers(managedDisposer, null);
}
protected DisposableObject(Action managedDisposer, Action unmanagedDisposer)
{
AddDisposers(managedDisposer, unmanagedDisposer);
}
public bool IsDisposed
{
get { return disposeIndex == -1; }
}
public void CheckDisposed()
{
if (IsDisposed)
throw new ObjectDisposedException("This instance is disposed.");
}
protected void AddDisposers(Action managedDisposer, Action unmanagedDisposer)
{
managedDisposers.Add(managedDisposer);
unmanagedDisposers.Add(unmanagedDisposer);
disposeIndex++;
}
protected void AddManagedDisposer(Action managedDisposer)
{
AddDisposers(managedDisposer, null);
}
protected void AddUnmanagedDisposer(Action unmanagedDisposer)
{
AddDisposers(null, unmanagedDisposer);
}
public void Dispose()
{
if (disposeIndex != -1)
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
~DisposableObject()
{
if (disposeIndex != -1)
Dispose(false);
}
private void Dispose(bool disposing)
{
for (; disposeIndex != -1; --disposeIndex)
{
if (disposing)
if (managedDisposers[disposeIndex] != null)
managedDisposers[disposeIndex]();
if (unmanagedDisposers[disposeIndex] != null)
unmanagedDisposers[disposeIndex]();
}
}
private readonly IList<Action> managedDisposers = new List<Action>();
private readonly IList<Action> unmanagedDisposers = new List<Action>();
private int disposeIndex = -1;
}
This is a "complete" implementation in the sense I provide support for finalization (knowing most implementations don't need a finalizer), checking whether an object is disposed, etc. A real implementation may remove the finalizer, for example, or create a subclass of DisposableObject that includes the finalizer. Basically, I threw in everything I could think of just for this question.
There are probably some edge cases and esoteric situations I've missed, so I invite anyone to poke holes in this approach or to shore it up with corrections.
Other alternatives might be to use a single Queue<Disposer> disposers in DisposableObject instead of two lists; in this case, as disposers are called, they are removed from the list. There are other slight variations I can think of, but they have the same general result: no boilerplate code.

The first issue you will potentially hit is that C# only allows you to inherit from a single base class, which in this case will always be DisposableObject. Right here you have cluttered your class hierarchy by forcing additional layers so that classes that need to inherit from DisposableObject and some other object can do so.
You are also introducing a lot of overhead and maintenance issues down the road with this implementation (not to mention the repeated training costs everytime someone new comes on to the project and you have to explain how they should use this implementation rather than the defined pattern). You know have multiple states to keep track of with your two lists, there is no error handling around the calls to the actions, the syntax when calling an action looks "wierd" (while it may be common to invoke a method from an array, the syntax of simply putting the () after the array access just looks strange).
I understand the desire to reduce the amount of boilerplate you have to write, but disposability is generally not one of those areas that I would recommend taking short-cuts or otherwise deviating from the pattern. The closest I usually get is to use a helper method (or an extension method) that wraps the actual call to Dispose() on a given object. These calls typically look like:
if (someObject != null)
{
someObject.Dispose();
}
This can be simplified using a helper method, but keep in mind that FxCop (or any other static analysis tool that checks for correct dispose implementations) will complain.
As far as performance is concerned, keep in mind that you are making a lot of delegate calls with this type of implementation. This is, by nature of a delegate, somewhat more costly than a normal method call.
Maintainability is definately an issue here. As I mentioned, you have the repeated training costs everytime someone new comes on to the project and you have to explain how they should use this implementation rather than the defined pattern. Not only that, you have problems with everyone remembering to add their disposable objects to your lists.
Overall, I think doing this is a bad idea that will cause a lot of problems down the road, especially as the project and team size increase.

I occasionally have need for tracking several open files at a time or other resources. When I do I use a utility class similar to the following. Then the object still implements the Displose() as you suggest, even tracking multiple lists (managed/unmanaged) is easy and obvious to developers whats going on. Additionally the derivation from the List object is no accident, it allows you call Remove(obj) if needed. My constructor usually looks like:
_resources = new DisposableList<IDisposable>();
_file = _resources.BeginUsing(File.Open(...));
And here is the class:
class DisposableList<T> : List<T>, IDisposable
where T : IDisposable
{
public bool IsDisposed = false;
public T BeginUsing(T item) { base.Add(item); return item; }
public void Dispose()
{
for (int ix = this.Count - 1; ix >= 0; ix--)
{
try { this[ix].Dispose(); }
catch (Exception e) { Logger.LogError(e); }
this.RemoveAt(ix);
}
IsDisposed = true;
}
}

I like the general pattern from csharptest's answer. Having a base class designed around disposal is a bit limiting, but if you're using vb.net or don't mind some games with thread-static variables, a specially-designed base class will make it possible to register variables for disposal even when they're created in field initializers or derived-class constructors (normally, if an exception is thrown in a field initializer, there's no way to dispose any already-allocated IDisposable fields, and if the constructor of a derived class throws an exception there's no way for the partially-created base object to dispose itself).
I wouldn't bother with your unmanaged resources list, though. Classes with finalizers shouldn't hold references to any objects not required for finalization. Instead, the stuff needed for finalization should be placed in its own class, and the "main" class should create an instance of that latter class and keep a reference to it.

Is this IDisposable implementation correct?

I can never remember all the rules for implementing the IDisposable interface, so I tried to come up with a base class that takes care of all of this and makes IDisposable easy to implement. I just wanted to hear your opinion if this implementation is ok as it is or whether you see something I could improve. The user of this base class is supposed to derive from it and then implement the two abstract methods ReleaseManagedResources() and ReleaseUnmanagedResources(). So here is the code:
public abstract class Disposable : IDisposable
{
private bool _isDisposed;
private readonly object _disposeLock = new object();
/// <summary>
/// called by users of this class to free managed and unmanaged resources
/// </summary>
public void Dispose() {
DisposeManagedAndUnmanagedResources();
}
/// <summary>
/// finalizer is called by garbage collector to free unmanaged resources
/// </summary>
~Disposable() { //finalizer of derived class will automatically call it's base finalizer
DisposeUnmanagedResources();
}
private void DisposeManagedAndUnmanagedResources() {
lock (_disposeLock) //make thread-safe
if (!_isDisposed) { //make sure only called once
try { //suppress exceptions
ReleaseManagedResources();
ReleaseUnmanagedResources();
}
finally {
GC.SuppressFinalize(this); //remove from finalization queue since cleaup already done, so it's not necessary the garbage collector to call Finalize() anymore
_isDisposed = true;
}
}
}
private void DisposeUnmanagedResources() {
lock (_disposeLock) //make thread-safe since at least the finalizer runs in a different thread
if (!_isDisposed) { //make sure only called once
try { //suppress exceptions
ReleaseUnmanagedResources();
}
finally {
_isDisposed = true;
}
}
}
protected abstract void ReleaseManagedResources();
protected abstract void ReleaseUnmanagedResources();
}

I can't really comment on the correctness of your code, but I question whether you'll find having the Disposable class at the base of your inheritance tree as flexible as it needs to be. It's won't be much use when you want to inherit from something you don't own. I think that IDispoasble is left as an interface because of the many different domains across which it might be used. Providing a concrete implementation at the foot of the inheritance hierarchy would be... limiting.

You are accessing the managed object _disposeLock in the finalizer. It may have already been garbage-collected by then. Not sure what the implications of this would be as you are only using it to lock.
Thread-safety seems like overkill. I don't think you need to worry about contention between the GC thread and your application thread.
Otherwise it looks correct.

EDIT Yes, I misread the portion about separating disposing managed and unmanaged resources (still on first cup of coffee).
However the lock is still almost certainly not necessary. Yes, during a passive dispose the code will be running on the finalizer thread which is different than the thread it originally ran on. However if the object is being finalized in this fashion the CLR has already determined there are no existing references to this object and hence collected it. So there is no other place which can be calling your dispose at that time and hence there is no reason for a lock.
A couple of other style comments.
Why make the methods abstract? By doing so you are forcing derived classes to implement methods to dispose of managed and unmanaged resources even if they don't have any to dispose. True there is no point in deriving from this class if you don't have anything to dispose. But I think it's fairly common to only have one or the other but not both. I would make them virtual vs. abstract.
Also you prevent double dispose but you do nothing to warning the developer that they are double disposing an object. I realize the MSDN documentation says that double dispose should be essentially a no-op but at the same time under what circumstances should this be legal? In general it's a bad idea to access an object after it's been disposed. A double dispose necessitates a disposed object being reused and is likely a bug (this can happen if finalization is not suppressed in an active dispose but that's also a bad idea). If I were implementing this I would throw on double dispose to warn the developer they were using an object incorrectly (that is using it after it was already disposed).

If you are concerned about the thread safety then I'd use the lightweight interlocked operations rather than a heavyweight lock:
class MyClass: IDispose {
int disposed = 0;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public virtual void Dispose(bool disposing)
{
if (0 == Thread.InterlockedCompareExchange(ref disposed, 1, 0))
{
if (disposing)
{
// release managed resources here
}
// release unmanaged resources here
}
}
~MyClass()
{
Dispose(false);
}
}