David Gardiner - Azure Functions

ConfigureFunctionsWorkerDefaults vs ConfigureFunctionsWebApplication in .NET Azure Functions

2025-04-01T21:30:00.000+10:30

When you're creating a .NET Azure Function using the isolated worker model, the default template creates code that has the host builder configuration calling ConfigureFunctionsWorkerDefaults.

But if you want to enable ASP.NET Core integration features (which you would do if you wanted to work directly with HttpRequest, HttpResponse, and IActionResult types in your functions), then the documentation suggests to instead call ConfigureFunctionsWebApplication.

Usefully, once you add a package reference to Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore, you'll also get a .NET code analyzer error AZFW0014 if you're not calling ConfigureFunctionsWebApplication, so the compiler will ensure you're doing the right thing.

But apart from the integration with ASP.NET Core, are there any other significant differences between calling the two methods?

Because the code is hosted on GitHub, we can easily review the source code to find out.

ConfigureFunctionsWorkerDefaults

ConfigureFunctionsWorkerDefaults is defined in the WorkerHostBuilderExtensions class in the https://github.com/Azure/azure-functions-dotnet-worker project. There are a number of overloads, but they all end up calling this implementation:

public static IHostBuilder ConfigureFunctionsWorkerDefaults(this IHostBuilder builder, Action<HostBuilderContext, IFunctionsWorkerApplicationBuilder> configure, Action<WorkerOptions>? configureOptions)
{
    builder
        .ConfigureHostConfiguration(config =>
        {
            // Add AZURE_FUNCTIONS_ prefixed environment variables
            config.AddEnvironmentVariables("AZURE_FUNCTIONS_");
        })
        .ConfigureAppConfiguration(configBuilder =>
        {
            configBuilder.AddEnvironmentVariables();

            var cmdLine = Environment.GetCommandLineArgs();
            RegisterCommandLine(configBuilder, cmdLine);
        })
        .ConfigureServices((context, services) =>
        {
            IFunctionsWorkerApplicationBuilder appBuilder = services.AddFunctionsWorkerDefaults(configureOptions);

            // Call the provided configuration prior to adding default middleware
            configure(context, appBuilder);

            static bool ShouldSkipDefaultWorkerMiddleware(IDictionary<object, object> props)
            {
                return props is not null &&
                    props.TryGetValue(FunctionsApplicationBuilder.SkipDefaultWorkerMiddlewareKey, out var skipObj) &&
                    skipObj is true;
            }

            if (!ShouldSkipDefaultWorkerMiddleware(context.Properties))
            {
                // Add default middleware
                appBuilder.UseDefaultWorkerMiddleware();
            }
        });

    // Invoke any extension methods auto generated by functions worker sdk.
    builder.InvokeAutoGeneratedConfigureMethods();

    return builder;
}

ConfigureFunctionsWebApplication

ConfigureFunctionsWebApplication is defined in the FunctionsHostBuilderExtensions class. Whiles the source code is in the same GitHub project as ConfigureFunctionsWorkerDefaults, it ships as part of the Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore NuGet package.

It too contains a number of overloads, but they all end up calling this implementation:

public static IHostBuilder ConfigureFunctionsWebApplication(this IHostBuilder builder, Action<HostBuilderContext, IFunctionsWorkerApplicationBuilder> configureWorker)
{
    builder.ConfigureFunctionsWorkerDefaults((hostBuilderContext, workerAppBuilder) =>
    {
        workerAppBuilder.UseAspNetCoreIntegration();
        configureWorker?.Invoke(hostBuilderContext, workerAppBuilder);
    });

    builder.ConfigureAspNetCoreIntegration();

    return builder;
}

internal static IHostBuilder ConfigureAspNetCoreIntegration(this IHostBuilder builder)
{
    builder.ConfigureServices(services =>
    {
        services.AddSingleton<FunctionsEndpointDataSource>();
        services.AddSingleton<ExtensionTrace>();
        services.Configure<ForwardedHeadersOptions>(options =>
        {
            // By default, the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers
            // are sent by the host and will be processed by the worker.
            options.ForwardedHeaders = ForwardedHeaders.All;
        });
    });

    builder.ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.UseUrls(HttpUriProvider.HttpUriString);
        webBuilder.Configure(b =>
        {
            b.UseForwardedHeaders();
            b.UseRouting();
            b.UseMiddleware<WorkerRequestServicesMiddleware>();
            b.UseEndpoints(endpoints =>
            {
                var dataSource = endpoints.ServiceProvider.GetRequiredService<FunctionsEndpointDataSource>();
                endpoints.DataSources.Add(dataSource);
            });
        });
    });

    return builder;
}

So they're actually quite different!

Conclusion

I feel like the documentation suggesting using one or the other may be misleading. More likely you want to add a call to ConfigureFunctionsWebApplication but leave the call to ConfigureFunctionsWorkerDefaults (unless you really want to add in all your own calls to ConfigureHostConfiguration and ConfigureAppConfiguration)

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureFunctionsWorkerDefaults()
    .Build();

Looks like I'm not alone with this either.

.NET Azure Functions, Isolated worker model, Serilog to App Insights

2025-02-10T08:00:00.000+10:30

There's already some good resources online about configuring .NET Azure Functions with Serilog. For example, Shazni gives a good introduction to Serilog and then shows how to configure for in-process and isolated Azure Functions, and Simon shows how to use Serilog with Azure Functions in isolated worker model, but neither cover using App Insights.

It's important to note that the in-process model goes out of support (along with .NET 8) in November 2026. Going forward, only the isolated worker model is supported by future versions of .NET (starting with .NET 9)

The Serilog Sink package for logging data to Application Insights is Serilog.Extensions.AppInsights, and it has some useful code samples in the README, but they also lack mentioning the differences for isolated worker model.

So my goal here is to demonstrate the following combination:

A .NET Azure Function
That is using isolated worker mode
That logs to Azure App Insights
Uses Serilog for structured logging
Uses the Serilog 'bootstrapper' pattern to capture any errors during startup/configuration

Note: There are full working samples for this post in https://github.com/flcdrg/azure-function-dotnet-isolated-logging.

Our starting point is an Azure Function that has Application Insights enabled. We uncommented to the two lines in Program.cs and the two .csproj file from the default Functions project template.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

One of the challenges with using the App Insights Serilog Sink, is that it needs to be configured with an existing TelemetryConfiguration. The old way of doing this was to reference TelemetryConfiguration.Active, however using this property has been discouraged in .NET Core (aka modern .NET).

Instead you're encouraged to retrieve a valid TelemetryConfiguration instance from the service provider, like this:

Log.Logger = new LoggerConfiguration()
    .WriteTo.ApplicationInsights(
        serviceProvider.GetRequiredService<TelemetryConfiguration>(),
    TelemetryConverter.Traces)
    .CreateLogger();

Except we have a problem. How can we reference the service provider? We need to move this under the HostBuilder, so we have access to a service provider.

There's a couple of ways to do this. Traditionally we would use UseSerilog to register Serilog similar to this:

    var build = Host.CreateDefaultBuilder(args)
        .UseSerilog((_, services, loggerConfiguration) => loggerConfiguration
            .Enrich.FromLogContext()
            .Enrich.WithProperty("ExtraInfo", "FuncWithSerilog")

            .WriteTo.ApplicationInsights(
                services.GetRequiredService<TelemetryConfiguration>(),
                TelemetryConverter.Traces))

But as of relatively recently, you can now also use AddSerilog, as it turns out under the covers, UseSerilog just calls AddSerilog.

So this is the equivalent:

builder.Services
    .AddSerilog((serviceProvider, loggerConfiguration) =>
    {
        loggerConfiguration
            .Enrich.FromLogContext()
            .Enrich.WithProperty("ExtraInfo", "FuncWithSerilog")

            .WriteTo.ApplicationInsights(
                serviceProvider.GetRequiredService<TelemetryConfiguration>(),
                TelemetryConverter.Traces);
    })

There's also the 'bootstrap logging' pattern that was first outlined here.

This can be useful if you want to log any configuration errors at start up. The only issue here is it will be tricky to log those into App Insights as you won't have the main Serilog configuration (where you wire up App Insights integration) completed yet. You could log to another sink (Console, or Debug if you're running locally).

Here's an example that includes bootstrap logging.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.ApplicationInsights.Extensibility;
using Serilog;

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .WriteTo.Debug()
    .CreateBootstrapLogger();

try
{
    Log.Warning("Starting up.."); // Only logged to console

    var build = Host.CreateDefaultBuilder(args)
        .UseSerilog((_, services, loggerConfiguration) => loggerConfiguration
            .Enrich.FromLogContext()
            .Enrich.WithProperty("ExtraInfo", "FuncWithSerilog")

            .WriteTo.ApplicationInsights(
                services.GetRequiredService<TelemetryConfiguration>(),
                TelemetryConverter.Traces))

        .ConfigureFunctionsWebApplication()

        .ConfigureServices(services => {
            services.AddApplicationInsightsTelemetryWorkerService();
            services.ConfigureFunctionsApplicationInsights();
        })
        .ConfigureLogging(logging =>
        {
            // Remove the default Application Insights logger provider so that Information logs are sent
            // https://learn.microsoft.com/azure/azure-functions/dotnet-isolated-process-guide?tabs=hostbuilder%2Clinux&WT.mc_id=DOP-MVP-5001655#managing-log-levels
            logging.Services.Configure<LoggerFilterOptions>(options =>
            {
                LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
                    == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
                if (defaultRule is not null)
                {
                    options.Rules.Remove(defaultRule);
                }
            });
        })

        .Build();

    build.Run();
    Log.Warning("After run");
}
catch (Exception ex)
{
    Log.Fatal(ex, "An unhandled exception occurred during bootstrapping");
}
finally
{
    Log.Warning("Exiting application");
    Log.CloseAndFlush();
}

In my experimenting with this, when the Function is closed normally (eg. by being requested to stop in the Azure Portal / or pressing Ctrl-C in the console window when running locally) I was not able to get any logging working in the finally block. I think by then it's pretty much game over and the Function Host is keen to wrap things up.

But what if the Function is running in Azure? The Debug or Console sinks won't be much use there. In ApplicationInsights sink docs, there's a section on how to flush messages manually. The code sample shows creating a new instance of TelemetryClient so that you can use the ApplicationInsights sink in the bootstrap logger.

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .WriteTo.Debug()
    .WriteTo.ApplicationInsights(new TelemetryClient(new TelemetryConfiguration()), new TraceTelemetryConverter())
    .CreateBootstrapLogger();

If I simulate a configuration error by throwing an exception inside the ConfigureServices call, then you do get data sent to App Insights. eg.

{
    "name": "AppExceptions",
    "time": "2025-02-08T06:32:25.4548247Z",
    "tags": {
        "ai.cloud.roleInstance": "Delphinium",
        "ai.internal.sdkVersion": "dotnetc:2.22.0-997"
    },
    "data": {
        "baseType": "ExceptionData",
        "baseData": {
            "ver": 2,
            "exceptions": [
                {
                    "id": 59941933,
                    "outerId": 0,
                    "typeName": "System.InvalidOperationException",
                    "message": "This is a test exception",
                    "hasFullStack": true,
                    "parsedStack": [
                        {
                            "level": 0,
                            "method": "Program+<>c.<<Main>$>b__0_1",
                            "assembly": "FuncWithSerilog, Version=1.2.6.0, Culture=neutral, PublicKeyToken=null",
                            "fileName": "D:\\git\\azure-function-dotnet-isolated-logging\\net9\\FuncWithSerilog\\Program.cs",
                            "line": 36
                        },
                        {
                            "level": 1,
                            "method": "Microsoft.Extensions.Hosting.HostBuilder.InitializeServiceProvider",
                            "assembly": "Microsoft.Extensions.Hosting, Version=9.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60",
                            "line": 0
                        },
                        {
                            "level": 2,
                            "method": "Microsoft.Extensions.Hosting.HostBuilder.Build",
                            "assembly": "Microsoft.Extensions.Hosting, Version=9.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60",
                            "line": 0
                        },
                        {
                            "level": 3,
                            "method": "Program.<Main>$",
                            "assembly": "FuncWithSerilog, Version=1.2.6.0, Culture=neutral, PublicKeyToken=null",
                            "fileName": "D:\\git\\azure-function-dotnet-isolated-logging\\net9\\FuncWithSerilog\\Program.cs",
                            "line": 21
                        }
                    ]
                }
            ],
            "severityLevel": "Critical",
            "properties": {
                "MessageTemplate": "An unhandled exception occurred during bootstrapping"
            }
        }
    }
}

So there you go!

And this is all well and good, but it's important to mention that Microsoft are suggesting for new codebases use OpenTelemetry instead of App Insights! I'll have to check out how that works soon.

Azure Function posting an RSS feed to Mastodon

2024-01-13T13:00:00.000+10:30

Twitter (or 'X' as it seems to be called now), to my surprise, hasn't died yet. I'm still there, but I must say I'm enjoying the discussions over on Mastodon a lot more (follow me at https://mastodon.online/@DavidRGardiner). But there are a few feeds that I follow on Twitter that I'd like to follow on Mastodon. So I wrote a little Azure Function to do that for me (and anyone else who is interested).

One that is relevant to living in South Australia, especially over the warmer months, given where I live is a bushfire-prone area, is keeping an eye on the updates from the Country Fire Service (known locally as the CFS). They have a Twitter account, but not a Mastodon account. If only there was a way to get their updates on Mastodon!

As it turns out, the CFS publish some RSS feeds. My first attempt was to make use of a service like Mastofeed, which in theory can take an RSS feed and post updates to Mastodon. But as I discovered, the RSS feed from the CFS has a few oddities that seem to prevent this from working correctly - it posted one update but then stopped. Here's an example of the RSS feed:

<?xml version='1.0' ?>
<rss version='2.0' xmlns:atom='http://www.w3.org/2005/Atom'>
  <channel>
    <atom:link href='https://data.eso.sa.gov.au/prod/cfs/criimson/cfs_current_incidents.xml' rel='self' type='application/rss+xml' />
    <ttl>15</ttl>
    <title>Country Fire Service - South Australia - Current Incidents</title>
    <link>https://www.cfs.sa.gov.au/incidents/</link>
    <description>Current Incidents</description>
    <item>
      <link>https://www.cfs.sa.gov.au/incidents/</link>
      <guid isPermaLink='false'>https://data.eso.sa.gov.au/prod/cfs/criimson/1567212.</guid>
      <title>TIERS ROAD, LENSWOOD (Tree Down)</title>
      <identifier>1567212</identifier>
      <description>First Reported: Saturday, 06 Jan 2024 15:41:00&lt;br&gt;Status: GOING&lt;br&gt;Region: 1</description>
      <pubDate>Sat, 06 Jan 2024 16:15:03 +1030</pubDate>
    </item>

There is the identifier element that is non-standard, but I suspect the main issue is the guid element. For some reason, the isPermaLink attribute is set to false. On the face of it, that looks like a mistake. That URI (which incorporates the identifier value) does appear to be unique. With isPermaLink set to false, it hints that the value can't be used as a unique identifier. I'm guessing because of that, Mastofeed had no way to distinguish posts in the RSS feed.

So we're out of luck using the simple option. My next thought was whether there was something that could transform/fix up the RSS on the fly - an 'XSLT proxy' if you like, but I've not found a free offering like that.

Maybe I can write some code to do the job instead. Hosting it in an Azure Function should work, and ideally would be free (or really cheap).

An Azure Function

I ended up writing a relatively simple Azure Function in C# that polls the RSS feed every 15 minutes (as that's the value of the ttl element). It then posts any new items to Mastodon. Here's the code (Link to GitHub repo):

    [Function(nameof(CheckAlerts))]
    public async Task<List<CfsFeedItem>> CheckAlerts([ActivityTrigger] List<CfsFeedItem> oldList)
    {
        var newList = new List<CfsFeedItem>();

        var response = string.Empty;
        try
        {
            using var httpClient = _httpClientFactory.CreateClient();

            response = await httpClient.GetStringAsync(
                "https://data.eso.sa.gov.au/prod/cfs/criimson/cfs_current_incidents.xml");

            var xml = XDocument.Parse(response);

            if (xml.Root.Element("channel") is null)
                throw new InvalidOperationException("No channel element found in feed");

            var xmlItems = xml.Root.Element("channel")?.Elements("item").ToList();

            if (xmlItems is not null)
                foreach (var item in xmlItems)
                {
                    var dateTime = DateTime.Parse(item.Element("pubDate").Value);

                    newList.Add(new CfsFeedItem(
                        item.Element("guid").Value,
                        item.Element("title").Value,
                        item.Element("description").Value,
                        item.Element("link").Value,
                        dateTime
                    ));
                }

            // Find items in newList that are not in oldList
            var newItems = newList.Except(oldList).ToList();

            if (newItems.Any())
            {
                var accessToken = _settings.Token;
                var client = new MastodonClient(_settings.Instance, accessToken);

                foreach (var item in newItems)
                {
                    var message = $"{item.Title}\n\n{item.Description.Replace("<br>", "\n")}\n{item.Link}";

                    _logger.LogInformation("Tooting: {item}", message);

#if RELEASE
                await client.PublishStatus(message, Visibility.Unlisted);
#endif
                }
            }
            else
            {
                _logger.LogInformation("No new items found");
            }
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Problems. Data: {data}", response);
        }

        return newList;
    }

We keep a copy of the previous list of items, and then compare it to the new list. If there are any new items, we post them to Mastodon. Because we need to remember the previous run items, we need to use Durable Functions. This was my first time creating a Durable Function, so that also made it a good learning experience. The 'eternal orchestration' pattern is used, where the orchestration function calls itself, passing in the new list of items. Here's the orchestration function code:

    [Function(nameof(MonitorJobStatus))]
    public static async Task Run(
        [OrchestrationTrigger] TaskOrchestrationContext context, List<CfsFeedItem> lastValue)
    {
        var newValue = await context.CallActivityAsync<List<CfsFeedItem>>(nameof(CfsFunction.CheckAlerts), lastValue);

#if RELEASE
        // Orchestration sleeps until this time (TTL is 15 minutes in RSS)
        var nextCheck = context.CurrentUtcDateTime.AddMinutes(15);
#else
        var nextCheck = context.CurrentUtcDateTime.AddSeconds(20);
#endif

        await context.CreateTimer(nextCheck, CancellationToken.None);

        context.ContinueAsNew(newValue);
    }

The Durable Function infrastructure handles serialising and deserialising the list of items automatically. The Function takes a parameter that receives the list from the previous run. When the function completes, it returns the list that will be passed to the next run. The orchestration function passes in the list and sets things up to save the list so that it can be passed to the next run.

One thing about this pattern is you need some way of kickstarting the process. The way I chose was to add a HTTP trigger function that calls the orchestration function. The release pipeline makes a call to the HTTP trigger endpoint after it publishes the function.

Durable + .NET 8 + isolated

The Durable Function targets .NET 8 and uses the isolated model. It was a little challenging figuring out how to get this combination to work, as most of the documentation is either for the in-process model or for earlier versions of .NET. Ensuring that the appropriate NuGet packages were being referenced was tricky, as there are often different packages to use depending on the model and version of .NET. I ended up using the following packages:

    <PackageReference Include="Mastonet" Version="2.3.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
    <PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="8.0.0" />

Costs

To keep costs to a minimum, the Azure Function is running on a consumption plan. The intention is to keep it close to or under the free threshold.

As it turns out, so far the Function is not costing very much at all. It's actually the Storage Account that is the most significant. AUD8.30 so far and the total forecast for the month will be AUD17. An Azure Function needs to be linked to a Storage Account. It would be interesting to see if there are any changes I could make to reduce the cost further.

To see the latest posts from the Azure Function, you can go to https://mastodon.online/@CFSAlerts (and if you're on Mastodon, feel free to follow the account!)

Future enhancements

Apart from seeing if I can reduce the cost even more, the other thing that would be useful is to also track the daily fire bans. This data is published as an XML file, so parsing that once a day should be pretty straightforward.

You can find the full source code for the Azure Function in this GitHub repo.

Azure Functions - Enable specific functions for debugging

2021-08-04T13:52:00.000+09:30

I've been using Azure Functions quite a bit. Indeed I've been recently speaking about them and the new support for .NET 5 and soon .NET 6!

Today I wanted to debug an Azure Function application, but I didn't want all of the functions in the application to run (as some of them access resources that I don't have locally). I discovered that you can add a functions property to your host.json file to list the specific functions that should run.

eg.

{
  "version": "2.0",
  "functions": [
    "function1",
    "function2"
  ]
}

But I really would prefer not to edit host.json as that file is under source control and I'd then need to remember to not commit those changes. I'd much prefer not to have to remember too many things!

There's a section in the documentation that describes how you can also set these values in your local.settings.json (which isn't usually under source control). But the examples given are for simple boolean properties. How do you enter the array value?

To find out, I temporarily set the values in host.json and used the IConfigurationRoot.GetDebugView() extension method to dump out all the configuration to see how they were represented.

Here's the answer:

{
    "Values": {
        "AzureFunctionsJobHost__functions__0": "function1",
        "AzureFunctionsJobHost__functions__1": "function2"
    }
}

The __0 and __1 represent each element in the array. With that in place when I run the Azure Function locally, only function and function2 will run. All others will be ignored. Just add additional properties (incrementing the number) to enable more functions.