Introduction

Azure Functions is a serverless compute service that enables you to run event-driven code without managing infrastructure. Over time, Microsoft has introduced different hosting models for Azure Functions, including the in-process model and the isolated process model. The in-process model runs your function code in the same process as the Azure Functions host, while the isolated process model runs your function code in a separate process, providing greater flexibility and compatibility with different .NET versions. Migrating Azure Functions from the in-process model to the isolated worker model is a crucial step to ensure compatibility with future .NET versions and to leverage enhanced flexibility and control over your application's lifecycle. Microsoft has announced that support for the in-process model will end on November 10, 2026, making it imperative for developers to transition to the isolated worker model.

In this article, we’ll explore the reasons for migrating from the in-process model to the isolated process model, the key differences between the two, and a step-by-step guide to performing the migration with a detailed example.

Prerequisites

Understanding the In-Process vs. Isolated Worker Model

In-Process Model

Isolated Worker Model

Why Migrate to the Isolated Process Model?

Key Differences Between In-Process and Isolated Process Models

Feature In-Process Model Isolated Process Model
Hosting Runs in the same process as the runtime Runs in a separate process
.NET Version Support Limited to specific .NET versions Supports newer .NET versions (e.g., .NET 6+)
Dependency Management Shared with the runtime Isolated from the runtime
Startup Configuration Uses Startup.cs for dependency injection Uses Program.cs for dependency injection
Function Execution Directly integrated with the runtime Communicates with the runtime via gRPC


Step-by-Step Migration Guide

Let’s walk through the process of migrating an Azure Function from the in-process model to the isolated process model.

Step 1. Update the Project File.

The first step in migrating is updating the .csproj file to align with the isolated worker model requirements. Modify the .csproj file.

After applying these changes, the updated .csproj file should look like this.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <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.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Step 2. Modify Function Code.

Now we will see all the code changes we need to do in the Azure Functions.

Replace [FunctionName] with [Function].

[Function("MyFunction")]
public async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req, ILogger log)

Step 3. Configure Program.cs.

Unlike the in-process model, the isolated worker model requires a Program.cs file to define the function host.

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

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

host.Run();

Step 4. Update Host Configuration.

Ensure your local.settings.json file is configured correctly for the isolated process model.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

Azure Configuration Changes

Now we will see all the Azure configuration changes we need to do after the complete code deployment.

Change two environment variables in the Azure function.

Modify the Configuration--> General Settings, select the .NET Version .NET 8 Isolated as given in the below image.

Configuration

Other Package references

When migrating to the isolated worker model, you need to change the packages your application references. Depending on the triggers and bindings your app uses, your app might need to reference a different set of packages. The following table shows the replacements for some of the most used extensions.

Scenario In Proc Packages Changes to package references
Timer trigger Microsoft.Azure.Functions.Worker.Extensions.Timer
Blob bindings Microsoft.Azure.WebJobs.Extensions.Storage.Blobs Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Service Bus bindings Microsoft.Azure.WebJobs.Extensions.ServiceBus Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Durable Functions Microsoft.Azure.WebJobs.Extensions.DurableTask Microsoft.Azure.Functions.Worker.Extensions.DurableTask

These are some of the commonly used packages. There are lots of other packages that you may need to migrate based upon your project requirements. To know more please click here.

Conclusion

Migrating from the in-process model to the isolated process model for Azure Functions provides greater flexibility, improved performance, and better compatibility with newer .NET versions. By following the steps outlined in this article, you can successfully migrate your function app and take advantage of the benefits offered by the isolated process model. As Microsoft continues to invest in the isolated process model, it’s a good idea to migrate your existing function apps to ensure they remain supported and optimized for future updates. Happy coding!

Thank You, and Stay Tuned for More!

More Articles from my Account