Azure Function App migration to Isolated Worker Model

With .Net 8, Microsoft has completely stopped supporting In-Process working model for Azure Function Apps. If you are migrating your In-Process Function App to .Net 8 from earlier .Net versions, you need/have to migrate it to Isolated Worker Model.

What is Isolated Worker Model?

In Isolated worker model the code in the Function App gets executed in a separate process than the Function App itself. It has loads of benefits in this model which can be found in this Microsoft documentation.

Steps for Migration

1. In the .csproj file, verify the target framework needs to set to 8.0 (Please note, .Net 6.0 also supports the Isolated version along with In-Proc)
2. Verify in the .csproj that <OutputType>Exe</OutputType> tag is added/available
3. Then in the package references following needs to be added.

  <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

4. Then depending upon the Function trigger type additional package needs to be added.

e.g. For timer trigger Microsoft.Azure.Functions.Worker.Extensions.Timer package needs to be added and for service bus trigger Microsoft.Azure.Functions.Worker.Extensions.ServiceBus needs to be added.

The detailed table can be found here.

5. There is no Startup.cs class or FunctionsStartup attribute for Isolated model. It should be replaced with a Program.cs class.

6. Here is the important step to note. If you will not set up the HostBuilder correctly the Function App will not get triggered. The unpleasant part is, it will compile successfully and when hosted in Azure, will not throw any exception and invocation will look successful until you realize that the Function App Code is not getting executed.

Host builder Setup

If the Function App is HTTP Trigger based, the host builder should be setup with .ConfigureFunctionsWebApplication(). For all other trigger types .ConfigureFunctionsWorkerDefaults() should be used.

For example, for a timer trigger based Function App, HostBuilder initialization should look like the following.

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

And for a HTTP trigger based Function App, HostBuilder initialization should look like the following.

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

Function Attribute and Function Signature

In Isolated worker model, the FunctionName attribute is no more available. It is replaced with a “Function” attribute. One more significant code change required is the way to obtain the “ILogger<>” object. Instead of including the ILogger object as a parameter of the Function method as it was in In-Proc model, it should be injected in the Function class constructor. The following code snippet for a timer trigger based Function App can be referred as an example for the above two changes.

App Insights Logging in Isolated Model

After the migration you might experience an issue in the App Insights logging. Mostly, the root cause can be the improper logging initialization of Host Builder.

The following code snippet shows the correct way of setting up the builder for App Insights logging.

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

All the following code to setup logger correctly.

.ConfigureLogging(logging =>
    {
        logging.AddApplicationInsights();
        logging.AddFilter<<your_class_ref>>("", LogLevel.Information);
    })

FUNCTIONS_WORKER_RUNTIME Update

The final step of migration would be the configuration update in Azure. FUNCTION_WORKER_RUNTIME should be updated to “dotnet-isolated” in the hosting environment’s Environment Variable settings before releasing the binaries.

Happy Coding!!!