Introduction

CA2202 is the .NET analyzer rule that warns when the same IDisposable object might be disposed more than once. Sometimes double disposal is harmless because many framework classes make Dispose idempotent, but the analyzer is warning you that the ownership model in the code is unclear.

The right fix is usually not "suppress the warning". The real fix is to decide who owns the resource and ensure it is disposed exactly once by that owner.

A Common CA2202 Pattern

One classic trigger is mixing using with an explicit Dispose call.

using var stream = File.OpenRead(path);
// work with stream
stream.Dispose(); // CA2202 warning

The using statement already guarantees disposal at the end of the scope. The manual call is redundant and should be removed.

using var stream = File.OpenRead(path);
// work with stream

Nested Owners Can Also Trigger It

Another frequent cause is wrapping a stream in another disposable object and then disposing both when one already owns the other.

1using var fileStream = File.OpenRead(path);
2using var reader = new StreamReader(fileStream);
3
4string text = reader.ReadToEnd();

This can be valid because StreamReader.Dispose will also dispose the underlying stream, and some analyzers or review tools may still flag similar patterns depending on how ownership is expressed. If the wrapper should own the stream, the clearest fix is to let the wrapper be the only disposable in scope.

using var reader = new StreamReader(File.OpenRead(path));
string text = reader.ReadToEnd();

Preserve the Underlying Resource When Needed

Sometimes you do need both objects to stay alive independently. In that case, create the wrapper with leaveOpen: true so disposing the wrapper does not dispose the underlying stream.

1using var fileStream = File.OpenRead(path);
2using (var reader = new StreamReader(fileStream, leaveOpen: true))
3{
4    string firstLine = reader.ReadLine() ?? string.Empty;
5    Console.WriteLine(firstLine);
6}
7
8Console.WriteLine(fileStream.Position);

That makes ownership explicit and removes the double-dispose ambiguity.

Another Typical Case: try and finally

CA2202 often appears in older code that manually disposes an object in finally and also passes it into another disposal path.

1FileStream? stream = null;
2
3try
4{
5    stream = File.OpenRead(path);
6    // work with stream
7}
8finally
9{
10    stream?.Dispose();
11}

This is fine by itself, but if another object inside the try already disposes stream, the analyzer may complain. Modern C# usually reads better with using instead of hand-written try and finally.

Solving the Warning Systematically

When you see CA2202, ask these questions:

• Which object truly owns the disposable resource?
• Does any wrapper dispose the inner resource automatically?
• Can using express the ownership more clearly?
• If ownership is shared, can leaveOpen or a similar option separate the lifetimes?

That reasoning is more important than the exact syntax.

When Suppression Might Be Reasonable

There are rare cases where the analyzer cannot see that double disposal is benign and unavoidable. If you suppress the warning, do it only after confirming the type’s Dispose implementation is safe to call multiple times and the code clearly documents why.

In most ordinary application code, though, suppression is a sign that ownership was never simplified enough.

Common Pitfalls

The biggest mistake is disposing the same object both manually and through using. Pick one disposal path.

Another mistake is forgetting that many wrapper types own their inner streams by default. StreamReader, StreamWriter, GZipStream, and similar types often dispose the wrapped stream unless told otherwise.

Be careful with helper methods too. If one method disposes a stream that the caller still believes it owns, you can create CA2202 warnings and real lifetime bugs at the same time.

Finally, do not fix the warning by removing disposal entirely. The goal is single ownership, not no ownership.

Summary

• CA2202 warns that the same disposable object may be disposed more than once.
• The usual fix is to clarify ownership and dispose the resource in exactly one place.
• Remove redundant manual Dispose calls when using already handles cleanup.
• Use options such as leaveOpen when wrapper and underlying resource need separate lifetimes.
• Suppress the warning only when you have verified the ownership model and the dispose behavior are safe.