Reasons to use DI on a software project are numerous, and while one can argue that a micro-service should be so small that no IoC is needed, others may have their reasons to use it.

Not here to judge which approach is the best, but if you decide that DI is a must on your azure function project, you may find that the native support for DI does not allow you to use a third-party container as easy as you can see on a regular asp-net project. There are some libraries out there, but most uses some different techniques (such as DI using attributes) not alike to the code style on asp-net projects.

That is the reason I decided to write a library to fill this gap, and create an easy DI setup code as similar to asp-net as possible. That means you will be able to create classes with interfaces as parameters of a constructor, without the need of anything else but registering dependencies accordingly.

Find below a basic function example, observe that classes and functions are not declared as static, and dependencies are passed to the constructor just like in a regular asp-net project.

    public class Function1 : Disposable
    {
        public Function1(IService1 service1, ILogger logger)
        {
            // ...
        }

        [FunctionName(nameof(Function1))]
        public async Task Run(
            [QueueTrigger("myqueue-items", Connection = "AzureWebJobsStorage")]
            string myQueueItem
        )
        {
            await Task.Delay(2000);
            _logger.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        }

        // ...
    }

You will also find in the github project, a sample project that demonstrates the IDisposable classes being disposed at the end of a function run.

Head to the project's read-me and check out code examples.

Please feel free to contribute creating issues with feedback and pull requests.