FunctionContext accessor .NET 5+ (.NET isolated) Azure Functions

Usage

Add to your Program.cs file

.ConfigureFunctionsWorkerDefaults(applicationBuilder => applicationBuilder.UseFunctionContextAccessor())

and

.ConfigureServices(services => services.AddFunctionContextAccessor())

Final result would look something like this:
Program.cs

using Functions.Worker.ContextAccessor;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureAppConfiguration(configBuilder => configBuilder.AddEnvironmentVariables())
    .ConfigureFunctionsWorkerDefaults(applicationBuilder => applicationBuilder.UseFunctionContextAccessor())
    .ConfigureServices(services => services.AddFunctionContextAccessor())
    .ConfigureServices(Startup.Configure)
    .UseDefaultServiceProvider((_, options) =>
    {
        options.ValidateScopes = true;
        options.ValidateOnBuild = true;
    })
    .Build();

host.Run();

Scope Validation

It is strongly recommended that scopes are validated as seen by the inclusion of

.UseDefaultServiceProvider((_, options) =>
{
    options.ValidateScopes = true;
    options.ValidateOnBuild = true;
})

because unintended behavior may occur when there's no validation.

Why

As of this writting, the interface IFunctionsWorkerMiddleware does NOT have a IFunctionsWorkerMiddlewareFactory counterpart and gets registered as a singleton. As opposed to ASP.NET Core's IMiddleware which DOES have an IMiddlewareFactory counterpart and will allow the middleware to be registered with either a scoped or instance lifetime. This resulted in scoped access to the FunctionContext only being available to the function method and context information cannot be easily injected into other parts of the application.

This library is modeled after the implementation of HttpContextAccessor (usage seen here) and is inspired by @dolphinspired's gist.