Develop Reference

Implementing both IDisposable and IAsyncDisposable

Say I have a non-sealed class that does not deal with any unmanaged resources. I need to make a single async call during its disposing stage to do some clean up. There are no other managed resources to deal with.
From what I understand, in order to make the async clean up call, I must implement IAsyncDisposable and use the DisposeAsync() and DisposeAsyncCore() methods. But the guidance says that you should also implement the dispose pattern when you implement the async dispose pattern. This is all fine but there's nothing really I need to do in the Dispose().
So my question is, should the Dispose() logic be empty or do I need something to do the async cleanup in a synchronous way? (see comment in code about "What if anything should go here").
public class MyClass : IDisposable, IAsyncDisposable
{
private bool disposed;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
public async ValueTask DisposeAsync()
{
await DisposeAsyncCore().ConfigureAwait(false);
Dispose(false);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// What if anything should go here?
}
disposed = true;
}
}
protected virtual async ValueTask DisposeAsyncCore()
{
// Make async cleanup call here e.g. Database.CleanupAsync();
}
}

Example to those who still hesitate to implement both:
internal class Program
{
static void Main(string[] args)
{
foreach (var a in new B()){}
//IAsyncDisposable is not called - you leaking resources.
//No deadlocks in UI, no warning in compilation, nothing.
//So it is better to be on safe side and implement both
//because you never know how one will manage lifetime of your class.
}
public class B : IEnumerable, IAsyncEnumerable<object>
{
public IEnumerator GetEnumerator() => new A();
public IAsyncEnumerator<object> GetAsyncEnumerator(CancellationToken ct) => new A();
}
public class A : IAsyncEnumerator<object>, IEnumerator
{
public ValueTask DisposeAsync()
{
Console.WriteLine("Async Disposed");
return ValueTask.CompletedTask;
}
public bool MoveNext() => false;
public void Reset(){}
public ValueTask<bool> MoveNextAsync() => ValueTask.FromResult(false);
public object Current => null;
}
}
Conclusion
You can freely add support for async version only, but beware: some wraps, like foreach or older versions of DI containers (Ninject, StructureMap, etc), code generators like RestSharp, or proxy generators like Castle.Proxy might not support IAsyncDisposable. Failing to cast object to IDisposable will present hard to catch bugs in your app. Whereas if you do implement it, the worst thing that could happen is deadlock in finally block (if you do it through sync-over-async).
In general, it is better to support both operations if you plan to make it public API or you don't have control over your class lifetime (like in DI containers or other widely known wrappers).
How to
There is full Microsoft example on how to implement both of them in inheritable class (non-sealed, like in your example) - https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-disposeasync#implement-both-dispose-and-async-dispose-patterns
class ExampleConjunctiveDisposableusing : IDisposable, IAsyncDisposable
{
IDisposable? _disposableResource = new MemoryStream();
IAsyncDisposable? _asyncDisposableResource = new MemoryStream();
public void Dispose()
{
Dispose(disposing: true);
GC.SuppressFinalize(this);
}
public async ValueTask DisposeAsync()
{
await DisposeAsyncCore().ConfigureAwait(false);
Dispose(disposing: false);
#pragma warning disable CA1816 // Dispose methods should call SuppressFinalize
GC.SuppressFinalize(this);
#pragma warning restore CA1816 // Dispose methods should call SuppressFinalize
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
_disposableResource?.Dispose();
(_asyncDisposableResource as IDisposable)?.Dispose();
_disposableResource = null;
_asyncDisposableResource = null;
}
}
protected virtual async ValueTask DisposeAsyncCore()
{
if (_asyncDisposableResource is not null)
{
await _asyncDisposableResource.DisposeAsync().ConfigureAwait(false);
}
if (_disposableResource is IAsyncDisposable disposable)
{
await disposable.DisposeAsync().ConfigureAwait(false);
}
else
{
_disposableResource?.Dispose();
}
_asyncDisposableResource = null;
_disposableResource = null;
}
}

Both implementations of dispose feature is from the callers point of view. Your class would then offer both mechanisms to dispose off any managed and unmanaged resources and the caller application decides what to choose. This also ensures that any consumer which is unable to make use of asynchronous patterns are not lost.
You do not really need to implement synchronous dispose if you are sure about or want to force asynchronous consumption of your class.
So depending on your vision of class usage, you can choose how to dispose objects. If you choose to keep both mechanisms, you can dispose all resources both ways.

As you have said, the class is non-sealed. For sealed classes, it's enough to implement I(Async)Disposable interface. The Disposable pattern exists because the derived class may want to add cleanup logic that can be either sync or async. You can't know. That's why you need to implement the whole pattern for sync and async cases.
For your question. Never block async call in sync Dispose method. It's a caller's responsibility to use your class correctly. If he decides to call Dispose instead of DisposeAsync and clear only sync resources it's his decision/mistake. If this async call in DisposeAsync is absolutely necessary for proper cleanup and it is controlled by you, consider adding sync equivalent to be used in Dispose method.

Memory leak due to undetached events inside BackgroundService

I have a memory leak caused by the code below, probably due to undetached events, and I don't know how to properly unsubscribe from them.
I have the interface IEventsHandler, declared as singleton, which exposes some events. This interface is used inside a BackgroundService, where a subscriber is attached to the event. When an AlertEvent occurs, a scope is created to use a service which stores the event inside the database.
Here is the code:
public class MyWorker : BackgroundService
{
private readonly IEventsHandler _eventsHandler;
private readonly IServiceProvider _serviceProvider;
public MyWorker(IEventsHandler eventsHandler,
IServiceProvider serviceProvider)
{
_eventsHandler = eventsHandler;
_serviceProvider = serviceProvider;
_eventsHandler.AlertOccurred += AlertEventOccurred;
}
private async void AlertEventOccurred(object sender, AlertEvent e)
{
using var scope = _serviceProvider.CreateScope();
var service = scope.ServiceProvider.GetRequiredService<AlertService>();
await service.SaveAlert(e);
}
}
public interface IEventsHandler
{
event EventHandler<AlertEvent> AlertOccurred;
Task AddAlertEventAsync(AlertEvent ev);
}
public class EventsHandler : IEventsHandler
{
public event EventHandler<AlertEvent> AlertOccurred;
public async Task AddAlertEventAsync(AlertEvent ev)
{
await Task.Run(() => AlertOccurred?.Invoke(this, ev));
}
}
PS any advice on bad practices used in the example code is welcome :-)
Thanks

BackgroundService implements IHostedService interface which has a couple of methods named StartAsync and StopAsync.
It's better to use these methods instead of class constructor to subscribe to your events and then unsubscribe from them.
This way
public override Task StartAsync(CancellationToken cancellationToken)
{
_eventsHandler.AlertOccurred += AlertEventOccurred;
return Task.CompletedTask;
}
public override Task StopAsync(CancellationToken cancellationToken)
{
_eventsHandler.AlertOccurred -= AlertEventOccurred;
return Task.CompletedTask;
}

If this is actually the cause of your memory leak, the fix is pretty simple. Just create a destructor and unsubscribe from the event.
A destructor is the opposite of a constructor in that it gets called right before the object gets garbage collected. It's denoted by a tilde (~) preceding the same syntax as a constructor (minus the parameters). Yours would look something like this:
~MyWorker(){
_eventsHandler.AlertOccurred -= AlertEventOccurred;
}

What's the recommended way to deal with leaked IAsyncDisposable instances?

I've been familiarizing myself with some of the things (that are planned to be) added in C# 8 & .NET Core 3.0, and am unsure on the correct way to implement IAsyncDisposable (at time of writing, this link has literally no guidance).
In particular, it is unclear to me what to do in the case when an instance isn't explicitly disposed - that is, it isn't wrapped in an async using(...) and .DisposeAsync() isn't explicitly called.
My first thought was to do that same thing I'd do when implementing IDisposable:
My DisposeAsync() implementation calls a DisposeAsync(bool disposing) with disposing: true
Implement a finalizer (with ~MyType()) that calls DisposeAsync(disposing: false)
DisposeAsync(bool disposing) actually frees and/or disposes everything, and suppresses finalizing if disposing == true.
My concerns are that there's nothing to await the results of DisposeAsync(bool) in the finalizer, and explicitly waiting in a finalizer seems really really dangerous.
Of course "just leak" also seems less than ideal.
To make this concrete, here's a (simplified) example class that does have a finalizer:
internal sealed class TestAsyncReader: IAsyncDisposable
{
private bool IsDisposed => Inner == null;
private TextReader Inner;
internal TestAsyncReader(TextReader inner)
{
Inner = inner;
}
// the question is, should this exist?
~TestAsyncReader()
{
DisposeAsync(disposing: false);
}
private ValueTask DisposeAsync(bool disposing)
{
// double dispose is legal, but try and do nothing anyway
if (IsDisposed)
{
return default;
}
// should a finalizer even exist?
if (disposing)
{
GC.SuppressFinalize(this);
}
// in real code some resources explicitly implement IAsyncDisposable,
// but for illustration purposes this code has an interface test
if (Inner is IAsyncDisposable supportsAsync)
{
var ret = supportsAsync.DisposeAsync();
Inner = null;
return ret;
}
// dispose synchronously, which is uninteresting
Inner.Dispose();
Inner = null;
return default;
}
public ValueTask DisposeAsync()
=> DisposeAsync(disposing: true);
}
So, is there any guidance around proper handling of leaked IAsyncDisposable instances?

Basing on examples of how it's implemented inside .NET Core classes (like here) and some recommendations from there, I'd say that when you need to implement IAsyncDisposable, the good practice would be to implement both IAsyncDisposable and IDisposable. In this case IAsyncDisposable will be only responsible for explicit scenarios when asyncronus disposal is needed, while IDisposable is supposed to be implemented as usual according to disposable pattern practices and it's going to serve all fallback scenarios including those when things come to finalization. Thus you don't need to have anything like DisposeAsync(bool disposing) - the asynchronous disposal cannot and shouldn't happen in a finalizer. The only bad news that you'll have to support both paths for resources reclaiming (synchronous and asynchronous).

Microsoft released their own guidance regarding this problem.
As in the accepted answer you should implement both interfaces
If you implement the IAsyncDisposable interface but not the IDisposable interface, your app can potentially leak resources. If a class implements IAsyncDisposable, but not IDisposable, and a consumer only calls Dispose, your implementation would never call DisposeAsync. This would result in a resource leak.
But also you may need to implement 2 dispose patterns:
using System;
using System.IO;
using System.Threading.Tasks;
class ExampleConjunctiveDisposableusing : IDisposable, IAsyncDisposable
{
IDisposable? _disposableResource = new MemoryStream();
IAsyncDisposable? _asyncDisposableResource = new MemoryStream();
public void Dispose()
{
Dispose(disposing: true);
GC.SuppressFinalize(this);
}
public async ValueTask DisposeAsync()
{
await DisposeAsyncCore().ConfigureAwait(false);
Dispose(disposing: false);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
_disposableResource?.Dispose();
(_asyncDisposableResource as IDisposable)?.Dispose();
_disposableResource = null;
_asyncDisposableResource = null;
}
}
protected virtual async ValueTask DisposeAsyncCore()
{
if (_asyncDisposableResource is not null)
{
await _asyncDisposableResource.DisposeAsync();
}
if (_disposableResource is IAsyncDisposable disposable)
{
await disposable.DisposeAsync();
}
else
{
_disposableResource?.Dispose();
}
_asyncDisposableResource = null;
_disposableResource = null;
}
}

"Dispose is cancel" sementic on C# Tasks

I wanted to have a Task implementation that whenever it is get disposed, the task associated is canceled. So I have the following naive implementation in mind
public class AutoCancelTask : Task, IDisposable
{
public static AutoCancelTask Create(Action<CancellationToken> a)
{
return new AutoCancelTask(a, new CancellationTokenSource());
}
private CancellationTokenSource cts;
internal AutoCancelTask(Action<CancellationToken> a, CancellationTokenSource cts)
:base((() => a(cts.Token)))
{ this.cts = cts; }
void IDisposable.Dispose(){
cts.Cancel();
Dispose();
}
}
To simplify I only consider the simplest Task constructor. Adding other constructors would not be hard anyway.
My concern is how the IDisposable interface is being implemented. Since Task also implements IDisposable, would the above code cause any problems in certain scenarios? More importantly, would the above code do the right thing?

Is it safe to wrap Application.Run(new Form()) with a using(...) { } statement?

I am using an external API to interface to a FireWire Camera. The API is propably written in C++ but thankfully it brings its own .NET wrapper DLLs. The API requires the following procedure:
ApiResource.Init();
// ... use the ressource here ...
ApiResource.CloseAll();
ApiResource.Release();
Because I need some specific handling code I decided to write a wrapper class for this. I need to keep the ressources open while my Form is open because of Event Handlers, etc. So I thought to make the wrapper easier to use I'd make it a singleton implementing IDisposable so I can wrap it in a using statement. The reason I want a Singleton is to have a controlled and limited way of calling the required API functions:
class Wrapper : IDisposable {
private Wrapper _instance;
public Wrapper Instance
{
get
{
if(_instance == null)
_instance = new Wrapper();
return _instance;
}
}
private Wrapper ()
{
ApiResource.Init();
_disposed = false;
}
// Finalizer is here just in case someone
// forgets to call Dispose()
~Wrapper() {
Dispose(false);
}
private bool _disposed;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if(!_disposed)
{
if(disposing)
{
}
ApiResource.CloseAll();
ApiResource.Release();
_instance = null;
log("Wrapper disposed.");
_disposed = true;
}
}
}
The way I want to use it is this:
using(Wrapper.Instance) {
Application.Run(new Form());
}
I'm quite new to C# so I am very unsure of a couple of things:
Will Dispose() always be called in the above using(Singleton.Instance) { ... }? My logging suggests "yes", but I'm unsure...
Is it safe to wrap Application.Run(...) with a using-statement?

The answer to both of your questions is yes:
Dispose() will always be called when the using block ends, unless Wrapper.Instance was null when the block began.
It is perfectly safe to wrap the call to Run() in a using block.