Dependency injection needs to support InitializeAsync()

[ghost]

If the injection object needs to access async methods there are only 2 options, 1) Use the IAsyncInitialization pattern presented by Stephen Cleary in Async OOP 2: Constructors, or 2) Use the Task.Run(() => instance.methodAsync()).Result method of access, neither of which is ideal.

There is a discussion to create async constructors (Discussion: async constructors), but that support is a long way off, if it ever materializes. So, I am proposing a variation Stephen Cleary's IAsyncInitialization interface where the ASP.NET injector will check the class for an implementation of IInitializeAsync (below) and execute the InitializeAsync() method of the class:

/// <summary>
/// Marks a type as requiring asynchronous initialization.
/// </summary>
public interface IInitializeAsync
{
    /// <summary>
    /// Asynchronously initialize the instance.
    /// </summary>
    Task InitializeAsync();
}

Implementing this would allow the constructor to remain lightweight, while still allowing dependencies to be injected. By allowing the InitializeAsync() method to perform the heavier weight initialization, with better exception logging/handling.

[davidfowl]

Generally, we don't add any features to the container that doesn't already work on all other existing container adapters. If you'd like to push this as a standard thing, then I'd suggest following up with container authors and drive a consensus. That's the bar for adding any new feature to DI.

[ghost]

@davidfowl where would those discussions be held?

[davidfowl]

The dependency injection symposium 2019... just kidding, right here is fine. Just ping the authors of said framework https://github.com/aspnet/Extensions/tree/master/src/DependencyInjection#dependencyinjection

[ghost]

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[udlose]

has this been added now for .NET 7?

[ghost]

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

[BrennanConroy]

No. Follow up on issues like dotnet/runtime#65656