Add support for Func<TArgs, Task> handlers for Core Autofac Events

[alistairjevans]

Fixes #1069

Added overloads for OnPreparing, OnActivating, OnActivated and OnRelease that allow you to provide a Func<Task> handler, so you can do async/await inside those methods.

OnPreparing, OnActivating and OnActivated are not 'true' async, because the implementations are basically just a utility wrapper around handler(args).ConfigureAwait(false).GetAwaiter().GetResult().

So they make it more convenient for developers to do some async operations inside these handlers, but there is no ResolveAsync method.

OnRelease has a bit more functionality, because if you dispose of the scope/container using DisposeAsync, that will do a proper await on the task, so it's an actual async flow.

[tillig]

The build failure here is really weird. I'm curious if it has to do with the build environment:

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/
Host (useful for support):
  Version: 5.0.0-preview.3.20214.6
  Commit:  b037784658

Which appears it's .NET 5 preview doing the building for a .NET Core 3.x runtime. Normally should be fine, but might have an edge case?

The build scripts skip install of the specific .NET Core SDK on Linux. I don't know if that needs to be fixed to make this work. I can help with that if you don't have a Linux environment to mess with. I was meaning to do it for my Mac build anyway. Let me know and I'll jump on it.

[alistairjevans]

That would be helpful, I don't have an equivalent Linux immediately to hand. Thanks.

[tillig]

OK, let me see what I can do. I'll probably just jam it right to v6 if it builds so you can pull it into your branch.

[alsami]

The build scripts skip install of the specific .NET Core SDK on Linux

Just FYI the script used to install the dotnet-sdk is not compatible with Unix bases systems, that's why I added the conditional installation.

[tillig]

Yup, there's a bash equivalent. I've updated the scripts and the build seems to work and pull the correct stuff for a Mac/Linux host now. Give that a shot; pushed to v6 directly.

[alistairjevans]

I think we need to update the analyser package.

dotnet/roslyn-analyzers#3642

[alistairjevans]

I'll just do that in this branch.

[tillig]

D'OH! 🍩

[alistairjevans]

Ok, that worked; I had to take the beta of the affected analysers.

[tillig]

Looks good.

I've thought about it since January when the issue first came up and it feels just a little weird that we'd allow for async stuff during preparing and activation, just because those things are supposed to be fast like a constructor. It is aligned with async disposal, though I feel like the difference is that when you're done with a thing it doesn't matter how long it might take to get rid of it, but when you need a thing, creating it should be fast... and adding something that requires async during object activation naturally implies you're doing something that isn't fast.

But, you know, I guess if folks want to add that overhead to their apps, that's not our problem.

I definitely would need to be sold on async resolution operations, should that come up. I don't want to encourage resolution things that are so slow that you'd need to async them.

Of course, just watch .NET add async constructors to the language in .NET 5.1 or something. 😩

[alistairjevans]

The best use-case I can see for this is when you are activating a SingleInstance 'thing', that requires some warmup or external resource, rather than a transient instance.

In a singleton scenario, this slow bit only runs once, and all subsequent resolves are fast.

I too am firmly against an async resolve pipeline (and async constructors...).

[tanveerbadar]

Thank you for this. I never got around to contributing this particular change myself, and probably would have done it as well as you could.