I was setting up a new Azure Function application to show off some further configuration settings usage but it wasn’t working. After some time and frustration I finally remembered it doesn’t work out of the box and you have to do additional plumbing to get it to work and not just add in the nuget package.


To get service dependencies registered and hence also configuration to be loaded you need to advance the DI capabilities of Azure functions by using the Microsoft.Azure.Functions.Extensions nuget package. This package allows for extending the DI capabilities of your Azure Functions application.

Once this package is loaded you need to add in a Startup class. This class I have modeled on the ASP.NET Core convention. This class will be the class which is used for configuring the application at startup and allowing all the dependencies to be registered.

public class Startup : FunctionsStartup
    public override void Configure(IFunctionsHostBuilder builder)
        // services are registered here

    public override void ConfigureAppConfiguration(IFunctionsConfigurationBuilder builder)
        FunctionsHostBuilderContext context = builder.GetContext();

            .AddJsonFile(Path.Combine(context.ApplicationRootPath, "appsettings.json"), optional: true, reloadOnChange: false)
            .AddJsonFile(Path.Combine(context.ApplicationRootPath, $"appsettings.{context.EnvironmentName}.json"), optional: true, reloadOnChange: false)

As with my earlier post I have set it up to load in an appsettings file which is configurable by environment much like a standard ASP.NET Core application. Unlike an ASP.NET Core application it has to derive from something (which I believe will change in the out of process hosted model in the future) but allows for further extension. As you can see from the above there are methods which are overrriden which look familiar. However this isn’t all you need to do!

Unlike an ASP.NET Core application which is a console application and spins up a host builder to configure and run your application current Azure Functions don’t have this ability. Due to this you have to tell the run time where the “Startup” class is. This is very similar to the OWIN pipeline registrations in full fat .NET Framework applications.

This is done by using the FunctionsStartup attribute which is derived itself from WebJobsStartupAttribute.

[assembly: FunctionsStartup(typeof(FunctionApp2.Startup))]

Once this is done your Azure Functions Application starts up and registers the dependecies as configured and any custom configuration will be loaded for future processing.


In this post we have looked at what is required to setup the ability to allow for dependencies to be registered and additional configuration to be loaded for your Azure Function App. The magic sauce isn’t just adding the nuget package but also specifying the startup attribute to get the ball rolling.

Any questions/comments/tips then please get in contact on Twitter @WestDiscGolf as I am still learning and would love to hear about pros and cons of doing what I’ve done with Azure Functions.