Migrate apps from Azure Functions version 3.x to version 4.x

These steps assume a local C# project, and if your app is instead using C# script (.csx files), you should convert to the project model before continuing.

The following changes are required in the .csproj XML project file:

1. Set the value of PropertyGroup.TargetFramework to net8.0.

2. Set the value of PropertyGroup.AzureFunctionsVersion to v4.

3. Add the following OutputType element to the PropertyGroup:

   <OutputType>Exe</OutputType>
   

4. Replace the existing ItemGroup.PackageReference list with the following ItemGroup:

   <ItemGroup>
     <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.19.0" />
     <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.14.1" />
   </ItemGroup>
   

5. Add the following new ItemGroup:

   <ItemGroup>
     <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
   </ItemGroup>
   

After you make these changes, your updated project should look like the following example:

<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>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.18.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.13.0" />
  </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>

The following changes are required in the .csproj XML project file:

1. Set the value of PropertyGroup.TargetFramework to net48.

2. Set the value of PropertyGroup.AzureFunctionsVersion to v4.

3. Add the following OutputType element to the PropertyGroup:

<OutputType>Exe</OutputType>

1. Replace the existing ItemGroup.PackageReference with the following ItemGroup:

<ItemGroup>
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.19.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.14.0" />
</ItemGroup>

1. Add the following new ItemGroup:

<ItemGroup>
  <Folder Include="Properties\" />
</ItemGroup>

After you make these changes, your updated project should look like the following example:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.18.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.0.13" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.13.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

The following changes are required in the .csproj XML project file:

1. Change the value of PropertyGroup.TargetFramework to net6.0.

2. Change the value of PropertyGroup.AzureFunctionsVersion to v4.

3. Replace the existing ItemGroup.PackageReference list with the following ItemGroup:

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>

After you make these changes, your updated project should look like the following example:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Update your project to reference the latest stable versions of:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

Depending on the triggers and bindings your app uses, your app may need to reference an additional set of packages. See Supported bindings for a list of extensions to consider, and consult each extension's documentation for full installation instructions for the isolated process model. The packages for these extensions will all be under the Microsoft.Azure.Functions.Worker.Extensions prefix. Be sure to install the latest stable version of any packages you are targeting.

Your application should not reference any packages in the Microsoft.Azure.WebJobs.* namespaces. If you have any remaining references to these, they should be removed.

Update your project to reference the latest stable versions of:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

Depending on the triggers and bindings your app uses, your app may need to reference an additional set of packages. See Supported bindings for a list of extensions to consider, and consult each extension's documentation for full installation instructions for the isolated process model. The packages for these extensions will all be under the Microsoft.Azure.Functions.Worker.Extensions prefix. Be sure to install the latest stable version of any packages you are targeting.

Your application should not reference any packages in the Microsoft.Azure.WebJobs.* namespaces. If you have any remaining references to these, they should be removed.

Update your project to reference the latest stable version of Microsoft.NET.Sdk.Functions.

Depending on the triggers and bindings your app uses, your app may need to reference an additional set of packages. See Supported bindings for a list of extensions to consider, and consult each extension's documentation for full installation instructions for the in-process process model. Be sure to install the latest stable version of any packages you are targeting.

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();

This example includes ASP.NET Core integration to improve performance and provide a familiar programming model when your app uses HTTP triggers. If you do not intend to use HTTP triggers, you can replace the call to ConfigureFunctionsWebApplication with a call to ConfigureFunctionsWorkerDefaults. If you do so, you can remove the reference to Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore from your project file. However, for the best performance, even for functions with other trigger types, you should keep the FrameworkReference to ASP.NET Core.

The Program.cs file will replace any file that has the FunctionsStartup attribute, which is typically a Startup.cs file. In places where your FunctionsStartup code would reference IFunctionsHostBuilder.Services, you can instead add statements within the .ConfigureServices() method of the HostBuilder in your Program.cs. To learn more about working with Program.cs, see Start-up and configuration in the isolated worker model guide.

The default Program.cs examples above include setup of Application Insights integration for the isolated worker model. In your Program.cs, you must also configure any log filtering that should apply to logs coming from code in your project. In the isolated worker model, the host.json file only controls events emitted by the Functions host runtime. If you don't configure filtering rules in Program.cs, you may see differences in the log levels present for various categories in your telemetry.

Although you can register custom configuration sources as part of the HostBuilder, note that these similarly apply only to code in your project. Trigger and binding configuration is also needed by the platform, and this should be provided through the application settings, Key Vault references, or App Configuration references features.

Once you have moved everything from any existing FunctionsStartup to the Program.cs file, you can delete the FunctionsStartup attribute and the class it was applied to.

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

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

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

The Program.cs file will replace any file that has the FunctionsStartup attribute, which is typically a Startup.cs file. In places where your FunctionsStartup code would reference IFunctionsHostBuilder.Services, you can instead add statements within the .ConfigureServices() method of the HostBuilder in your Program.cs. To learn more about working with Program.cs, see Start-up and configuration in the isolated worker model guide.

The default Program.cs examples above include setup of Application Insights integration for the isolated worker model. In your Program.cs, you must also configure any log filtering that should apply to logs coming from code in your project. In the isolated worker model, the host.json file only controls events emitted by the Functions host runtime. If you don't configure filtering rules in Program.cs, you may see differences in the log levels present for various categories in your telemetry.

Although you can register custom configuration sources as part of the HostBuilder, note that these similarly apply only to code in your project. Trigger and binding configuration is also needed by the platform, and this should be provided through the application settings, Key Vault references, or App Configuration references features.

Once you have moved everything from any existing FunctionsStartup to the Program.cs file, you can delete the FunctionsStartup attribute and the class it was applied to.

A Program.cs file isn't required when you are using the in-process model.

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1"
    }
}

No changes are required to your host.json file. However, if your Application Insights configuration in this file from your in-process model project, you might want to make additional changes in your Program.cs file. The host.json file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See Managing log levels in the isolated worker model for details on how to filter these logs.

No changes are required to your host.json file. However, if your Application Insights configuration in this file from your in-process model project, you might want to make additional changes in your Program.cs file. The host.json file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See Managing log levels in the isolated worker model for details on how to filter these logs.

No changes are required to your host.json file.

This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check Breaking changes between 3.x and 4.x for additional changes you might need to make to your project.

JSON serialization

By default, the isolated worker model uses System.Text.Json for JSON serialization. To customize serializer options or switch to JSON.NET (Newtonsoft.Json), see these instructions.

Application Insights log levels and filtering

Logs can be sent to Application Insights from both the Functions host runtime and code in your project. The host.json allows you to configure rules for host logging, but to control logs coming from your code, you'll need to configure filtering rules as part of your Program.cs. See Managing log levels in the isolated worker model for details on how to filter these logs.

This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check Breaking changes between 3.x and 4.x for additional changes you might need to make to your project.

JSON serialization

By default, the isolated worker model uses System.Text.Json for JSON serialization. To customize serializer options or switch to JSON.NET (Newtonsoft.Json), see these instructions.

Application Insights log levels and filtering

Logs can be sent to Application Insights from both the Functions host runtime and code in your project. The host.json allows you to configure rules for host logging, but to control logs coming from your code, you'll need to configure filtering rules as part of your Program.cs. See Managing log levels in the isolated worker model for details on how to filter these logs.

Make sure to check Breaking changes between 3.x and 4.x for additional changes you might need to make to your project.

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Sames as version 3.x (in-process).