If you've ever seen "too many open files" errors or database connection pool exhaustion, you've experienced what happens when resources aren't released promptly. The garbage collector eventually cleans up objects, but it can't know that your file handle or network socket needs immediate release. That's where IDisposable comes in.
The Dispose method gives you control over exactly when resources get released. Unlike finalizers that run unpredictably during garbage collection, Dispose runs immediately when you call it. This deterministic cleanup prevents resource exhaustion and ensures file locks release, database transactions commit, and network connections close at precise moments in your code flow.
You'll learn the standard dispose pattern that handles both managed and unmanaged resources correctly, how using statements automate disposal, common implementation mistakes that cause leaks, and modern async disposal for asynchronous cleanup operations. We'll build examples that show proper ownership semantics and demonstrate why disposal matters for application reliability.
IDisposable defines a single method: Dispose(). Implementing it correctly requires following a well-established pattern that handles repeated calls, supports inheritance, and integrates with the garbage collector. The pattern ensures resources get cleaned up exactly once, even when consumers call Dispose multiple times or forget to call it entirely.
A proper implementation tracks whether disposal has occurred using a boolean flag. This makes Dispose idempotent—safe to call multiple times. The pattern also separates managed and unmanaged resource cleanup through a protected virtual Dispose(bool disposing) method that derived classes can override safely.
public class FileLogger : IDisposable
{
private FileStream? fileStream;
private StreamWriter? writer;
private bool disposed = false;
public FileLogger(string path)
{
fileStream = new FileStream(path, FileMode.Append);
writer = new StreamWriter(fileStream);
}
public void Log(string message)
{
if (disposed)
throw new ObjectDisposedException(nameof(FileLogger));
writer?.WriteLine($"{DateTime.Now:yyyy-MM-dd HH:mm:ss} - {message}");
writer?.Flush();
}
public void Dispose()
{
Dispose(disposing: true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Dispose managed resources
writer?.Dispose();
fileStream?.Dispose();
}
// Free unmanaged resources here (if any)
disposed = true;
}
}
}
// Proper usage with using statement
void ProperUsage()
{
using (var logger = new FileLogger("app.log"))
{
logger.Log("Application started");
logger.Log("Processing data");
} // Dispose called automatically here
}The using statement ensures Dispose gets called even if exceptions occur within the block. It's syntactic sugar for a try-finally that calls Dispose in the finally block. This pattern is so common that C# 8 introduced using declarations that dispose at the end of the enclosing scope rather than requiring explicit braces.
When your class contains IDisposable fields, your class becomes responsible for disposing them. This ownership relationship means you must implement IDisposable yourself and call Dispose on owned objects in your Dispose method. Failing to do this creates resource leaks because the garbage collector won't automatically dispose fields.
The key principle is clear ownership. If your class creates a disposable object and stores it as a field, your class owns it and must dispose it. If you receive a disposable object as a constructor parameter or method argument, you typically don't own it unless documentation explicitly states you're taking ownership.
public class DatabaseRepository : IDisposable
{
private SqlConnection? connection;
private SqlCommand? command;
private bool disposed = false;
public DatabaseRepository(string connectionString)
{
// We create these, so we own them
connection = new SqlConnection(connectionString);
command = connection.CreateCommand();
}
public async Task<List<User>> GetUsersAsync()
{
if (disposed)
throw new ObjectDisposedException(nameof(DatabaseRepository));
command!.CommandText = "SELECT Id, Name, Email FROM Users";
await connection!.OpenAsync();
var users = new List<User>();
using (var reader = await command.ExecuteReaderAsync())
{
while (await reader.ReadAsync())
{
users.Add(new User
{
Id = reader.GetInt32(0),
Name = reader.GetString(1),
Email = reader.GetString(2)
});
}
}
return users;
}
public void Dispose()
{
Dispose(disposing: true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// Dispose owned resources in reverse order of creation
command?.Dispose();
connection?.Dispose();
}
disposed = true;
}
}
}
public class User
{
public int Id { get; set; }
public string Name { get; set; } = string.Empty;
public string Email { get; set; } = string.Empty;
}Notice how we dispose resources in reverse order of creation. This mimics stack unwinding and ensures dependencies clean up correctly. The command depends on the connection, so we dispose the command first, then the connection. Following this pattern prevents errors during cleanup.
C# 8 introduced using declarations that simplify the syntax for disposable objects. Instead of wrapping code in using statement braces, you declare a variable with the using keyword, and it automatically disposes at the end of the enclosing scope. This reduces nesting and makes code more readable.
The using declaration works particularly well in methods where you need multiple disposable resources. Each declaration adds to a list of resources to dispose when the method exits, maintaining proper disposal order without deeply nested using blocks.
public class FileProcessor
{
// C# 8+ using declaration - disposes at end of method
public void ProcessFileModern(string sourcePath, string destPath)
{
using var source = new FileStream(sourcePath, FileMode.Open);
using var dest = new FileStream(destPath, FileMode.Create);
using var reader = new StreamReader(source);
using var writer = new StreamWriter(dest);
string? line;
while ((line = reader.ReadLine()) != null)
{
writer.WriteLine(line.ToUpper());
}
// All resources dispose here in reverse order:
// writer, reader, dest, source
}
// Traditional using statement (still valid)
public void ProcessFileTraditional(string sourcePath, string destPath)
{
using (var source = new FileStream(sourcePath, FileMode.Open))
using (var dest = new FileStream(destPath, FileMode.Create))
using (var reader = new StreamReader(source))
using (var writer = new StreamWriter(dest))
{
string? line;
while ((line = reader.ReadLine()) != null)
{
writer.WriteLine(line.ToUpper());
}
}
}
// Expression-bodied using for simple cases
public string ReadFileContent(string path)
{
using var reader = new StreamReader(path);
return reader.ReadToEnd();
}
}The modern using declaration makes the code cleaner by eliminating the visual clutter of braces. The compiler generates identical IL code for both approaches, so there's no performance difference. Choose whichever style fits your team's conventions and the specific method structure.
Some resources require asynchronous operations during cleanup. Flushing buffered data to disk or network, committing transactions, or properly closing async network streams all involve awaitable operations. IAsyncDisposable provides DisposeAsync for these scenarios, working alongside the traditional synchronous Dispose method.
When implementing both IDisposable and IAsyncDisposable, the async version should do the actual work, while the synchronous version can either throw NotSupportedException or provide a blocking fallback. This ensures callers use the appropriate disposal method for their context.
public class AsyncLogger : IAsyncDisposable, IDisposable
{
private FileStream? fileStream;
private StreamWriter? writer;
private bool disposed = false;
public AsyncLogger(string path)
{
fileStream = new FileStream(path, FileMode.Append, FileAccess.Write,
FileShare.None, 4096, useAsync: true);
writer = new StreamWriter(fileStream);
}
public async Task LogAsync(string message)
{
if (disposed)
throw new ObjectDisposedException(nameof(AsyncLogger));
await writer!.WriteLineAsync(
$"{DateTime.Now:yyyy-MM-dd HH:mm:ss} - {message}");
await writer.FlushAsync();
}
public async ValueTask DisposeAsync()
{
if (!disposed)
{
if (writer != null)
{
await writer.DisposeAsync();
}
if (fileStream != null)
{
await fileStream.DisposeAsync();
}
disposed = true;
}
GC.SuppressFinalize(this);
}
public void Dispose()
{
// Synchronous fallback
if (!disposed)
{
writer?.Dispose();
fileStream?.Dispose();
disposed = true;
}
GC.SuppressFinalize(this);
}
}
// Usage with await using
async Task UseAsyncLogger()
{
await using (var logger = new AsyncLogger("async.log"))
{
await logger.LogAsync("Async operation started");
await Task.Delay(100);
await logger.LogAsync("Async operation completed");
} // DisposeAsync called automatically
// Or with C# 8+ declaration syntax
await using var logger2 = new AsyncLogger("async2.log");
await logger2.LogAsync("Using declaration style");
}The await using statement works like using but calls DisposeAsync instead of Dispose. This ensures asynchronous cleanup operations complete properly. DisposeAsync returns ValueTask rather than Task to avoid allocation in cases where disposal can complete synchronously.
Build a resource management example that demonstrates proper disposal patterns and what happens when disposal fails. You'll see why using statements matter for reliability.
class ResourceTracker : IDisposable
{
private readonly string name;
private bool disposed = false;
public ResourceTracker(string resourceName)
{
name = resourceName;
Console.WriteLine($"[{name}] Resource acquired");
}
public void UseResource()
{
if (disposed)
throw new ObjectDisposedException(name);
Console.WriteLine($"[{name}] Using resource");
}
public void Dispose()
{
if (!disposed)
{
Console.WriteLine($"[{name}] Resource disposed");
disposed = true;
}
}
}
Console.WriteLine("=== Proper disposal with using ===");
using (var res1 = new ResourceTracker("File1"))
{
res1.UseResource();
}
Console.WriteLine("After using block\n");
Console.WriteLine("=== Without using (leak) ===");
var res2 = new ResourceTracker("File2");
res2.UseResource();
// Oops! Never disposed
Console.WriteLine("Method ending without disposal\n");
Console.WriteLine("=== Nested using ===");
using (var outer = new ResourceTracker("Outer"))
using (var inner = new ResourceTracker("Inner"))
{
outer.UseResource();
inner.UseResource();
}
Console.WriteLine("Both disposed in reverse order");<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
</Project>Steps:
dotnet new console -n DisposeDemocd DisposeDemodotnet runRun result:
=== Proper disposal with using ===
[File1] Resource acquired
[File1] Using resource
[File1] Resource disposed
After using block
=== Without using (leak) ===
[File2] Resource acquired
[File2] Using resource
Method ending without disposal
=== Nested using ===
[Outer] Resource acquired
[Inner] Resource acquired
[Outer] Using resource
[Inner] Using resource
[Inner] Resource disposed
[Outer] Resource disposed
Both disposed in reverse orderNotice that File2 never disposes because we didn't use a using statement. In a real application, this would leak the resource until garbage collection eventually runs finalizers. The nested using example shows proper disposal order—inner resources dispose before outer ones, maintaining dependency relationships.
Testing disposal behavior ensures your resource management works correctly under all scenarios. You should verify that Dispose can be called multiple times safely, that disposed objects throw ObjectDisposedException when used, and that all owned resources get disposed in the correct order.
Mock disposable dependencies to verify your class disposes them. Use dispose tracking wrappers in tests to confirm disposal happens at the right time. Integration tests should verify that resources like file handles and database connections actually get released, not just that Dispose methods execute.
using Xunit;
public class DisposableTests
{
[Fact]
public void Dispose_CanBeCalledMultipleTimes()
{
// Arrange
var resource = new ResourceTracker("Test");
// Act
resource.Dispose();
resource.Dispose();
resource.Dispose();
// Assert - no exception thrown
}
[Fact]
public void UsingDisposedObject_ThrowsObjectDisposedException()
{
// Arrange
var resource = new ResourceTracker("Test");
resource.Dispose();
// Act & Assert
Assert.Throws<ObjectDisposedException>(() => resource.UseResource());
}
[Fact]
public void Dispose_DisposesOwnedResources()
{
// Arrange
var tracker = new DisposableTracker();
var parent = new ParentResource(tracker);
// Act
parent.Dispose();
// Assert
Assert.True(tracker.WasDisposed);
}
}
class DisposableTracker : IDisposable
{
public bool WasDisposed { get; private set; }
public void Dispose() => WasDisposed = true;
}These tests verify the contract that IDisposable implementations must fulfill. Idempotent disposal prevents errors in complex scenarios where multiple code paths might dispose the same object. Throwing ObjectDisposedException helps callers detect bugs where they're using objects after disposal. Testing that owned resources dispose prevents subtle leaks.
Resources remain locked until the garbage collector runs finalizers, which might be seconds or minutes later. File handles, database connections, and sockets stay open, potentially exhausting system resources. Always use using statements to guarantee disposal.
Yes, Dispose must be idempotent. The standard pattern uses a boolean flag to ensure cleanup logic runs only once. Subsequent calls do nothing. This prevents errors when consumers call Dispose explicitly and also use using statements.
Yes, if your class owns IDisposable fields like FileStream or DbConnection. Your Dispose method should dispose those owned objects. You typically don't need a finalizer for managed-only scenarios since the owned objects handle their own finalization.
Close is typically domain-specific and might allow reopening the resource. Dispose indicates final cleanup with no intention to reuse. Many classes implement both, with Close calling Dispose internally. Stream.Close calls Stream.Dispose, for example.
Implement IAsyncDisposable with DisposeAsync for async cleanup. Use await using for automatic disposal. This pattern works when flushing buffers or closing connections requires awaitable operations. NetworkStream and modern EF Core contexts support this.
No, using disposed objects typically throws ObjectDisposedException. Well-implemented IDisposable classes check their disposed flag in methods and throw this exception. Never access disposed resources—always create new instances or implement object pooling if reuse is needed.