Migrera appar från Azure Functions version 1.x till version 4.x

  • Artikel

Viktigt!

Java stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din Java-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.

Viktigt!

TypeScript stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din TypeScript-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.

Viktigt!

PowerShell stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din PowerShell-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.

Viktigt!

Python stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera python-appen från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.

Viktigt!

Supporten upphör för version 1.x av Azure Functions-körningen den 14 september 2026. Vi rekommenderar starkt att du migrerar dina appar till version 4.x genom att följa anvisningarna i den här artikeln.

Den här artikeln beskriver hur du migrerar funktionsappen på ett säkert sätt och kör version 4.x av Functions-körningen. Eftersom instruktionerna för projektmigrering är språkberoende måste du välja utvecklingsspråk från väljaren överst i artikeln.

Om du kör version 1.x av körningen i Azure Stack Hub läser du Överväganden för Azure Stack Hub först.

Identifiera funktionsappar som ska migreras

Använd följande PowerShell-skript för att generera en lista över funktionsappar i din prenumeration som för närvarande är målversion 1.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Välj din .NET-målversion

I version 1.x av Functions-körningen riktar sig C#-funktionsappen mot .NET Framework.

När du migrerar funktionsappen har du möjlighet att välja målversionen av .NET. Du kan uppdatera C#-projektet till någon av följande versioner av .NET som stöds av Functions version 4.x:

.NET-version Versionstyp för .NET Official Support Policy Funktionsprocessmodell1,3
.NET 82 LTS Isolerad arbetsmodell
.NET 7 STS (support upphör 14 maj 2024) Isolerad arbetsmodell
.NET 6 LTS (support upphör 12 november 2024) Isolerad arbetsmodell,
Processmodell3
.NET Framework 4.8 Se princip Isolerad arbetsmodell

1 Den isolerade arbetsmodellen stöder versioner av .NET (Long Term Support) och Standard Term Support (STS) samt .NET Framework. Den processbaserade modellen stöder endast LTS-versioner av .NET. En fullständig funktionsjämförelse och funktionsjämförelse mellan de två modellerna finns i Skillnader mellan processer och isolera arbetsprocess .NET Azure Functions.

2 .NET 8 stöds ännu inte i den pågående modellen, även om den är tillgänglig för den isolerade arbetsmodellen. Information om .NET 8-planer, inklusive framtida alternativ för den processbaserade modellen, finns i Azure Functions-översiktsuppdateringsposten.

3 Supporten upphör för den pågående modellen den 10 november 2026. Mer information finns i det här supportmeddelandet. Om du vill ha fortsatt fullständigt stöd bör du migrera dina appar till den isolerade arbetsmodellen.

Dricks

Såvida inte appen är beroende av ett bibliotek eller API som endast är tillgängligt för .NET Framework rekommenderar vi att du uppdaterar till .NET 8 på den isolerade arbetsmodellen. Många appar på .NET Framework-målversion 1.x beror bara på att det var det som var tillgängligt när de skapades. Ytterligare funktioner är tillgängliga för nyare versioner av .NET, och om din app inte tvingas stanna kvar i .NET Framework på grund av ett beroende bör du rikta in dig på en senare version. .NET 8 är den fullständigt släppta versionen med det längsta supportfönstret från .NET.

Även om du kan välja att i stället använda den processbaserade modellen rekommenderas detta inte om det kan undvikas. Supporten upphör för den pågående modellen den 10 november 2026, så du måste gå över till den isolerade arbetsmodellen innan dess. Om du migrerar till version 4.x minskar den totala ansträngningen som krävs, och den isolerade arbetsmodellen ger appen ytterligare fördelar, inklusive möjligheten att enklare rikta in sig på framtida versioner av .NET. Om du flyttar till den isolerade arbetsmodellen kan .NET Upgrade Assistant också hantera många av de nödvändiga kodändringarna åt dig.

Den här guiden innehåller inte några specifika exempel för .NET 7 eller .NET 6 på den isolerade arbetsmodellen. Om du behöver rikta in dig på dessa versioner kan du anpassa .NET 8 isolerade arbetsmodellexempel.

Förbereda för migrering

Om du inte redan har gjort det kan du identifiera listan över appar som måste migreras i din aktuella Azure-prenumeration med hjälp av Azure PowerShell.

Innan du migrerar en app till version 4.x av Functions-körningen bör du utföra följande uppgifter:

  1. Granska listan över beteendeändringar efter version 1.x. Migrering från version 1.x till version 4.x kan också påverka bindningar.
  2. Slutför stegen i Migrera ditt lokala projekt för att migrera ditt lokala projekt till version 4.x.
  3. När du har migrerat projektet testar du appen lokalt med version 4.x av Azure Functions Core Tools.
  4. Uppdatera funktionsappen i Azure till den nya versionen. Om du behöver minimera stilleståndstiden bör du överväga att använda ett mellanlagringsfack för att testa och verifiera din migrerade app i Azure på den nya körningsversionen. Du kan sedan distribuera din app med de uppdaterade versionsinställningarna till produktionsplatsen. Mer information finns i Uppdatera med hjälp av platser.
  5. Publicera ditt migrerade projekt till den uppdaterade funktionsappen.

När du använder Visual Studio för att publicera ett version 4.x-projekt till en befintlig funktionsapp i en lägre version uppmanas du att låta Visual Studio uppdatera funktionsappen till version 4.x under distributionen. Den här uppdateringen använder samma process som definierats i Uppdatera utan fack.

Migrera ditt lokala projekt

I följande avsnitt beskrivs de uppdateringar som du måste göra i C#-projektfilerna för att kunna köras på en av de versioner av .NET som stöds i Functions version 4.x. De uppdateringar som visas är de som är gemensamma för de flesta projekt. Din projektkod kan kräva uppdateringar som inte nämns i den här artikeln, särskilt när du använder anpassade NuGet-paket.

Om du migrerar en C#-funktionsapp från version 1.x till version 4.x av Functions-körningen måste du göra ändringar i projektkoden. Många av dessa ändringar är ett resultat av ändringar i C#-språket och .NET-API:er.

Välj den flik som matchar målversionen av .NET och önskad processmodell (pågående eller isolerad arbetsprocess).

Dricks

Om du flyttar till en LTS- eller STS-version av .NET med hjälp av den isolerade arbetsmodellen kan .NET Upgrade Assistant användas för att automatiskt göra många av de ändringar som nämns i följande avsnitt.

Projektfil

Följande exempel är en .csproj projektfil som körs på version 1.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Använd någon av följande procedurer för att uppdatera XML-filen så att den körs i Functions version 4.x:

De här stegen förutsätter ett lokalt C#-projekt, och om din app i stället använder C#-skript (.csx filer) bör du konvertera till projektmodellen innan du fortsätter.

Följande ändringar krävs i .csproj XML-projektfilen:

  1. Ange värdet PropertyGroupför .TargetFramework till net8.0.

  2. Ange värdet PropertyGroupför .AzureFunctionsVersion till v4.

  3. Lägg till följande OutputType element i PropertyGroup:

    <OutputType>Exe</OutputType>

  4. ItemGroupI .PackageReference ersätter du paketreferensen till Microsoft.NET.Sdk.Functions med följande referenser:

      <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" />

    Anteckna eventuella referenser till andra paket i Microsoft.Azure.WebJobs.* namnrymderna. Du ersätter dessa paket i ett senare steg.

  5. Lägg till följande nya ItemGroup:

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

När du har genomfört de här ändringarna bör ditt uppdaterade projekt se ut som i följande exempel:

<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>

Paket- och namnområdesändringar

Baserat på den modell som du migrerar till kan du behöva uppdatera eller ändra paketen som dina programreferenser refererar till. När du antar målpaketen måste du uppdatera namnområdet för att använda -instruktioner och vissa typer som du refererar till. Du kan se effekten av dessa namnområdesändringar på using -instruktioner i http-utlösarmallsexemplen senare i den här artikeln.

Om du inte redan har gjort det uppdaterar du projektet så att det refererar till de senaste stabila versionerna av:

Beroende på vilka utlösare och bindningar som appen använder kan din app behöva referera till en annan uppsättning paket. I följande tabell visas ersättningarna för några av de vanligaste tilläggen:

Scenario Ändringar i paketreferenser
Timerutlösare Lägg till
Microsoft.Azure.Functions.Worker.Extensions.Timer
Lagringsbindningar Replace
Microsoft.Azure.WebJobs.Extensions.Storage
med
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues och
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blobbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Köbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabellbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Tables
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.CosmosDB
Eller
Microsoft.Azure.WebJobs.Extensions.DocumentDB
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.ServiceBus
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.EventHubs
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.EventGrid
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.SignalRService
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Bestående funktioner Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.DurableTask
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Bestående funktioner
(SQL-lagringsprovider)		 Ersätt referenser till
Microsoft.DurableTask.SqlServer.AzureFunctions
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Bestående funktioner
(Netherite Storage-provider)		 Ersätt referenser till
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.SendGrid
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Kafka
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Beroendeinmatning
och startkonfiguration		 Ta bort referenser till
Microsoft.Azure.Functions.Extensions
(Den isolerade arbetsmodellen tillhandahåller den här funktionen som standard.)

Se Bindningar som stöds för en fullständig lista över tillägg att överväga och läs dokumentationen för varje tillägg för fullständiga installationsinstruktioner för den isolerade processmodellen. Se till att installera den senaste stabila versionen av alla paket som du riktar in dig på.

Dricks

Eventuella ändringar av tilläggsversioner under den här processen kan kräva att du även uppdaterar host.json filen. Läs dokumentationen för varje tillägg som du använder. Service Bus-tillägget har till exempel icke-bakåtkompatibla ändringar i strukturen mellan versionerna 4.x och 5.x. Mer information finns i Azure Service Bus-bindningar för Azure Functions.

Ditt isolerade arbetsmodellprogram bör inte referera till några paket i Microsoft.Azure.WebJobs.* namnrymderna eller Microsoft.Azure.Functions.Extensions. Om du har några återstående referenser till dessa bör de tas bort.

Dricks

Din app kan också vara beroende av Azure SDK-typer, antingen som en del av dina utlösare och bindningar eller som ett fristående beroende. Du bör också ta tillfället i akt att uppdatera dessa. De senaste versionerna av Functions-tilläggen fungerar med de senaste versionerna av Azure SDK för .NET, nästan alla paket som är formuläret Azure.*.

Bindningarna Notification Hubs och Mobile Apps stöds endast i version 1.x av körningen. När du uppgraderar till version 4.x av körningen måste du ta bort dessa bindningar till förmån för att arbeta med dessa tjänster direkt med sina SDK:er.

Program.cs fil

I de flesta fall kräver migrering att du lägger till följande program.cs fil i projektet:

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

Det här exemplet omfattar ASP.NET Core-integrering för att förbättra prestanda och tillhandahålla en välbekant programmeringsmodell när din app använder HTTP-utlösare. Om du inte tänker använda HTTP-utlösare kan du ersätta anropet till ConfigureFunctionsWebApplication med ett anrop till ConfigureFunctionsWorkerDefaults. Om du gör det kan du ta bort referensen till Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore från projektfilen. Men för bästa prestanda, även för funktioner med andra utlösartyper, bör du behålla FrameworkReference till ASP.NET Core.

Filen Program.cs ersätter alla filer som har FunctionsStartup attributet, vilket vanligtvis är en Startup.cs fil. På platser där koden FunctionsStartup refererar IFunctionsHostBuilder.Servicestill kan du i stället lägga till instruktioner i .ConfigureServices() -metoden HostBuilder i i .Program.cs Mer information om hur du arbetar med Program.csfinns i Start-up and configuration in the isolated worker model guide (Start-up and configuration in the isolated worker model guide).

Standardexemplen Program.cs ovan är installation av Application Insights-integrering för den isolerade arbetsmodellen. I måste Program.csdu även konfigurera loggfiltrering som ska gälla för loggar som kommer från kod i projektet. I den isolerade arbetsmodellen host.json styr filen endast händelser som genereras av Functions-värdkörningen. Om du inte konfigurerar filtreringsregler i Program.cskan du se skillnader i loggnivåerna för olika kategorier i telemetrin.

Även om du kan registrera anpassade konfigurationskällor som en del av HostBuilder, bör du tänka på att dessa på samma sätt endast gäller för kod i projektet. Utlösar- och bindningskonfiguration krävs också av plattformen, och detta bör tillhandahållas via funktionerna för programinställningar, Key Vault-referenser eller appkonfigurationsreferenser .

När du har flyttat allt från alla befintliga FunctionsStartup till Program.cs filen kan du ta bort FunctionsStartup attributet och den klass som det tillämpades på.

host.json fil

Inställningar i filen host.json gäller på funktionsappsnivå, både lokalt och i Azure. I version 1.x är din host.json fil tom eller innehåller vissa inställningar som gäller för alla funktioner i funktionsappen. Mer information finns i Host.json v1. Om din host.json-fil har inställningsvärden kan du granska host.json v2-format för eventuella ändringar.

Om du vill köra version 4.x måste du lägga till "version": "2.0" den host.json filen. Du bör också överväga att lägga logging till i konfigurationen, som i följande exempel:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

Filen host.json styr endast loggning från Functions-värdkörningen, och i den isolerade arbetsmodellen kommer vissa av dessa loggar direkt från ditt program, vilket ger dig mer kontroll. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .

local.settings.json fil

Filen local.settings.json används bara när den körs lokalt. Mer information finns i Filen Lokala inställningar. I version 1.x har local.settings.json-filen bara två obligatoriska värden:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

När du migrerar till version 4.x kontrollerar du att filen local.settings.json har minst följande element:

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

Kommentar

När du migrerar från att köras i processen till att köras i en isolerad arbetsprocess måste du ändra FUNCTIONS_WORKER_RUNTIME värdet till "dotnet-isolerad".

Ändringar i klassnamn

Vissa nyckelklasser ändrade namn mellan version 1.x och version 4.x. Dessa ändringar beror antingen på ändringar i .NET-API:er eller på skillnader mellan processprocess och isolerad arbetsprocess. Följande tabell anger viktiga .NET-klasser som används av Functions som kan ändras vid migrering:

Version 1.x .NET 8
FunctionName (attribut) Function (attribut)
TraceWriter ILogger<T>, ILogger
HttpRequestMessage HttpRequestData, HttpRequest (med hjälp av ASP.NET Core-integrering)
HttpResponseMessage HttpResponseData, IActionResult (med hjälp av ASP.NET Core-integrering)

Det kan också finnas skillnader i klassnamn i bindningar. Mer information finns i referensartiklarna för de specifika bindningarna.

Andra kodändringar

I det här avsnittet beskrivs andra kodändringar som du bör tänka på när du arbetar med migreringen. Dessa ändringar behövs inte av alla program, men du bör utvärdera om några är relevanta för dina scenarier. Kontrollera beteendeändringar efter version 1.x för ytterligare ändringar som du kan behöva göra i projektet.

JSON-serialisering

Som standard använder System.Text.Json den isolerade arbetsmodellen för JSON-serialisering. Om du vill anpassa serialiseraralternativ eller växla till JSON.NET (Newtonsoft.Json) kan du läsa de här anvisningarna.

Application Insights-loggnivåer och filtrering

Loggar kan skickas till Application Insights från både Functions-värdkörningen och koden i projektet. Gör host.json att du kan konfigurera regler för värdloggning, men för att styra loggar som kommer från din kod måste du konfigurera filtreringsregler som en del av din Program.cs. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .

HTTP-utlösarmall

De flesta kodändringarna mellan version 1.x och version 4.x kan ses i HTTP-utlösta funktioner. HTTP-utlösarmallen för version 1.x ser ut som i följande exempel:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<HttpResponseMessage> 
            Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", 
            Route = null)]HttpRequestMessage req, TraceWriter log)
        {
            log.Info("C# HTTP trigger function processed a request.");

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

I version 4.x ser HTTP-utlösarmallen ut som i följande exempel:

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"]}!");
        }
    }
}

Så här uppdaterar du projektet till Azure Functions 4.x:

  1. Uppdatera din lokala installation av Azure Functions Core Tools till version 4.x.

  2. Flytta till någon av de Node.js versioner som stöds på version 4.x.

  3. Lägg till både version och extensionBundle element i host.json, så att det ser ut som i följande exempel:

    {
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

    Elementet extensionBundle krävs eftersom bindningar bevaras som externa paket efter version 1.x. Mer information finns i Tilläggspaket.

  4. Uppdatera local.settings.json-filen så att den har minst följande element:

    {
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}

    Inställningen AzureWebJobsStorage kan vara antingen Azurite Storage-emulatorn eller ett faktiskt Azure-lagringskonto. Mer information finns i Lokal lagringsemulator.

Uppdatera funktionsappen i Azure

Du måste uppdatera körningen av funktionsappens värd i Azure till version 4.x innan du publicerar det migrerade projektet. Körningsversionen som används av Functions-värden styrs av programinställningen FUNCTIONS_EXTENSION_VERSION , men i vissa fall måste även andra inställningar uppdateras. Både kodändringar och ändringar i programinställningarna kräver att funktionsappen startas om.

Det enklaste sättet är att uppdatera utan platser och sedan publicera om ditt appprojekt. Du kan också minimera stilleståndstiden i din app och förenkla återställningen genom att uppdatera med hjälp av fack.

Uppdatera utan fack

Det enklaste sättet att uppdatera till v4.x är att ställa in programinställningen ~4 på i funktionsappen FUNCTIONS_EXTENSION_VERSION i Azure. Du måste följa en annan procedur på en plats med platser.

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Du måste också ange en annan inställning som skiljer sig mellan Windows och Linux.

När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

.NET 6 krävs för funktionsappar på alla språk som körs i Windows.

I det här exemplet ersätter du <APP_NAME> med namnet på din funktionsapp och <RESOURCE_GROUP_NAME> med namnet på resursgruppen.

Nu kan du publicera om ditt appprojekt som har migrerats för att köras på version 4.x.

Uppdatera med fack

Att använda distributionsplatser är ett bra sätt att uppdatera funktionsappen till v4.x-körningen från en tidigare version. Genom att använda ett mellanlagringsfack kan du köra appen på den nya körningsversionen på mellanlagringsplatsen och växla till produktion efter verifiering. Fack ger också ett sätt att minimera stilleståndstiden under uppdateringen. Om du behöver minimera stilleståndstiden följer du stegen i Uppdatering av minsta stilleståndstid.

När du har verifierat din app i det uppdaterade facket kan du växla appen och de nya versionsinställningarna till produktion. Den här växlingen kräver inställning WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 i produktionsplatsen. Hur du lägger till den här inställningen påverkar hur lång stilleståndstid som krävs för uppdateringen.

Standarduppdatering

Om din fackaktiverade funktionsapp kan hantera stilleståndstiden för en fullständig omstart kan du uppdatera WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS inställningen direkt i produktionsfacket. Eftersom en ändring av den här inställningen direkt i produktionsplatsen orsakar en omstart som påverkar tillgängligheten bör du överväga att göra den här ändringen i en tid med minskad trafik. Du kan sedan växla i den uppdaterade versionen från mellanlagringsplatsen.

Update-AzFunctionAppSetting PowerShell-cmdleten stöder för närvarande inte fack. Du måste använda Azure CLI eller Azure-portalen.

  1. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 i produktionsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME>

    I det här exemplet ersätter du <APP_NAME> med namnet på din funktionsapp och <RESOURCE_GROUP_NAME> med namnet på resursgruppen. Det här kommandot gör att appen som körs i produktionsfacket startas om.

  2. Använd följande kommando för att också ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS i mellanlagringsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  3. Använd följande kommando för att ändra FUNCTIONS_EXTENSION_VERSION och uppdatera mellanlagringsplatsen till den nya körningsversionen:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  4. Version 4.x av Functions-körningen kräver .NET 6 i Windows. I Linux måste .NET-appar också uppdateras till .NET 6. Använd följande kommando så att körningen kan köras på .NET 6:

    När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 krävs för funktionsappar på alla språk som körs i Windows.

    I det här exemplet ersätter du <APP_NAME> med namnet på din funktionsapp och <RESOURCE_GROUP_NAME> med namnet på resursgruppen.

  5. Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.

  6. Bekräfta att funktionsappen körs korrekt i den uppdaterade mellanlagringsmiljön innan du byter.

  7. Använd följande kommando för att växla den uppdaterade mellanlagringsplatsen till produktion:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Minsta stilleståndstidsuppdatering

För att minimera stilleståndstiden i produktionsappen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS kan du växla inställningen från mellanlagringsplatsen till produktion. Därefter kan du växla i den uppdaterade versionen från ett förvärmt mellanlagringsfack.

  1. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 i mellanlagringsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  2. Använd följande kommandon för att växla facket med den nya inställningen till produktion och samtidigt återställa versionsinställningen i mellanlagringsplatsen.

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    Du kan se fel från mellanlagringsplatsen under tiden mellan växlingen och körningsversionen som återställs vid mellanlagring. Det här felet kan inträffa eftersom WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 endast mellanlagring under en växling tar bort inställningen i mellanlagringen FUNCTIONS_EXTENSION_VERSION . Utan versionsinställningen är ditt fack i ett felaktigt tillstånd. Om du uppdaterar versionen i mellanlagringsplatsen direkt efter växlingen bör platsen återgå till ett bra tillstånd och du anropar återställ dina ändringar om det behövs. Men en återställning av växlingen kräver också att du tar bort WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 direkt från produktionen innan växlingen tillbaka för att förhindra samma fel i produktionen som visas i mellanlagringen. Den här ändringen i produktionsinställningen skulle sedan orsaka en omstart.

  3. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 igen i mellanlagringsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    Nu har WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 båda platserna angetts.

  4. Använd följande kommando för att ändra FUNCTIONS_EXTENSION_VERSION och uppdatera mellanlagringsplatsen till den nya körningsversionen:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  5. Version 4.x av Functions-körningen kräver .NET 6 i Windows. I Linux måste .NET-appar också uppdateras till .NET 6. Använd följande kommando så att körningen kan köras på .NET 6:

    När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 krävs för funktionsappar på alla språk som körs i Windows.

    I det här exemplet ersätter du <APP_NAME> med namnet på din funktionsapp och <RESOURCE_GROUP_NAME> med namnet på resursgruppen.

  6. Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.

  7. Bekräfta att funktionsappen körs korrekt i den uppdaterade mellanlagringsmiljön innan du byter.

  8. Använd följande kommando för att växla den uppdaterade och förinställda mellanlagringsplatsen till produktion:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Beteendeändringar efter version 1.x

I det här avsnittet beskrivs ändringar som gjorts efter version 1.x i både utlösar- och bindningsbeteenden samt i funktioner och beteenden i kärnfunktioner.

Ändringar i utlösare och bindningar

Från och med version 2.x måste du installera tilläggen för specifika utlösare och bindningar som används av funktionerna i appen. Det enda undantaget för dessa HTTP- och timerutlösare, som inte kräver något tillägg. Mer information finns i Registrera och installera bindningstillägg.

Det finns också några ändringar i function.json eller attribut för funktionen mellan versioner. Till exempel är egenskapen Event Hubs path nu eventHubName. Se den befintliga bindningstabellen för länkar till dokumentationen för varje bindning.

Ändringar i funktioner och funktioner

Några funktioner har tagits bort, uppdaterats eller ersatts efter version 1.x. Det här avsnittet beskriver de ändringar du ser i senare versioner efter att ha använt version 1.x.

I version 2.x gjordes följande ändringar:

  • Nycklar för att anropa HTTP-slutpunkter lagras alltid krypterade i Azure Blob Storage. I version 1.x lagrades nycklar som standard i Azure Files. När du migrerar en app från version 1.x till version 2.x återställs befintliga hemligheter som finns i Azure Files.

  • Version 2.x-körningen innehåller inte inbyggt stöd för webhook-leverantörer. Den här ändringen gjordes för att förbättra prestandan. Du kan fortfarande använda HTTP-utlösare som slutpunkter för webhooks.

  • För att förbättra övervakningen ersätts instrumentpanelen WebJobs i portalen, som använde AzureWebJobsDashboard inställningen med Azure Application Insights, som använder inställningen APPINSIGHTS_INSTRUMENTATIONKEY . Mer information finns i Övervaka Azure Functions.

  • Alla funktioner i en funktionsapp måste dela samma språk. När du skapar en funktionsapp måste du välja en körningsstack för appen. Körningsstacken FUNCTIONS_WORKER_RUNTIME anges av värdet i programinställningarna. Det här kravet har lagts till för att förbättra fotavtryck och starttid. När du utvecklar lokalt måste du även inkludera den här inställningen i filen local.settings.json.

  • Standardtimeouten för funktioner i en App Service-plan ändras till 30 minuter. Du kan manuellt ändra tidsgränsen tillbaka till obegränsad med hjälp av inställningen functionTimeout i host.json.

  • HTTP-samtidighetsbegränsningar implementeras som standard för funktioner i förbrukningsplanen, med standardvärdet 100 samtidiga begäranden per instans. Du kan ändra det här beteendet i maxConcurrentRequests inställningen i host.json-filen.

  • På grund av .NET Core-begränsningar har stöd för F#-skriptfunktioner (.fsx filer) tagits bort. Kompilerade F#-funktioner (.fs) stöds fortfarande.

  • URL-formatet för Event Grid-utlösarwebbhooks har ändrats för att följa det här mönstret: https://{app}/runtime/webhooks/{triggerName}.

  • Namnen på vissa fördefinierade anpassade mått ändrades efter version 1.x. Duration ersattes med MaxDurationMs, MinDurationMsoch AvgDurationMs. Success Rate har också bytt namn till Success Rate.

Överväganden för Azure Stack Hub

App Service på Azure Stack Hub stöder inte version 4.x av Azure Functions. När du planerar en migrering av version 1.x i Azure Stack Hub kan du välja något av följande alternativ:

  • Migrera till version 4.x som finns i det offentliga molnet Azure Functions med hjälp av anvisningarna i den här artikeln. I stället för att uppgradera din befintliga app skapar du en ny app med version 4.x och distribuerar sedan det ändrade projektet till den.
  • Växla till WebJobs som finns i en App Service-plan i Azure Stack Hub.

Nästa steg

Läs mer om Functions-versioner