Dela via

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

Azure Functions version 4.x är mycket bakåtkompatibel med version 3.x. De flesta appar bör migreras på ett säkert sätt till 4.x utan att det krävs betydande kodändringar. Mer information om Functions-körningsversioner finns i Översikt över Azure Functions-körningsversioner.

Viktigt!

Från och med den 13 december 2022 har Functions-appar som körs på versionerna 2.x och 3.x av Azure Functions-körningen nått slutet av utökad support. Mer information finns i Tillbakadragna versioner.

Den här artikeln beskriver hur du på ett säkert sätt migrerar din funktionsapp för att använda version 4.x av Functions-plattformen. Eftersom anvisningarna för projektmigrering är språkberoende, måste du välja utvecklingsspråk från alternativet överst i artikeln.

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ålversionerna 2.x eller 3.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 '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Välj din .NET-målversion

I version 3.x av Functions-körningen riktar sig C#-funktionsappen mot .NET Core 3.1 med hjälp av den processbaserade modellen eller .NET 5 med hjälp av den isolerade arbetsmodellen.

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,2
.NET 9 STS (support upphör 12 maj 2026) Isolerad arbetsmodell
.NET 8 LTS (support upphör 10 november 2026) Isolerad arbetsmodell,
Processmodell2
.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, som slutar med .NET 8. En fullständig funktions- och funktionalitetsjämförelse mellan de två modellerna finns i Skillnader mellan in-process- och isoleringsarbetsprocesser i .NET Azure Functions.

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

Tips

Vi rekommenderar att du uppdaterar till .NET 8 på den isolerade arbetsmodellen. .NET 8 är den fullständigt släppta versionen med det längsta supportfönstret från .NET.

Även om du i stället kan välja att använda den processbaserade modellen rekommenderar vi inte den här metoden om du kan undvika den. 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 9. Om du behöver rikta in dig på den versionen kan du anpassa .NET 8-exemplen för den isolerade arbetsmodellen.

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 brytande ändringar mellan 3.x och 4.x.
  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. Kör validatorn före uppgraderingen på appen som finns i Azure och lös eventuella identifierade problem.
  5. 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 slotar.
  6. 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

Uppgraderingsinstruktioner är språkberoende. Om du inte ser ditt språk, välj det från väljaren överst i artikeln.

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

Tips

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 använder .NET Core 3.1 på version 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </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. 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 XML-projektfilen .csproj :

  1. Ange värdet PropertyGroup. TargetFramework till net8.0.

  2. Ange värdet PropertyGroup. AzureFunctionsVersion till v4.

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

    <OutputType>Exe</OutputType>

  4. I ItemGroup. PackageReference listan, ersätt 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:

Scenarium Ändringar i paketreferenser
Timerutlösare Lägg till
Microsoft.Azure.Functions.Worker.Extensions.Timer
Lagringsbindningar Ersätt
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
och/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
Hållbara funktioner Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.DurableTask
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Hållbara funktioner
(SQL-lagringsprovider)		 Ersätt referenser till
Microsoft.DurableTask.SqlServer.AzureFunctions
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Hållbara 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 startinställningar		 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å.

Tips

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.

Tips

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

Program.cs fil

När du migrerar för att köras i en isolerad arbetsprocess måste du lägga 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 till IFunctionsHostBuilder.Services kan du i stället lägga till instruktioner i .ConfigureServices()-metoden av HostBuilder i din Program.cs. Mer information om hur du arbetar med Program.cs finns i Start-up and configuration in the isolated worker model guide (Starta och konfigurera i den isolerade arbetsmodellguiden).

Standardexemplen för Program.cs som beskrevs tidigare är installation av Application Insights. I din Program.cs måste du också konfigurera loggfiltrering som ska gälla för loggar som kommer från kod i projektet. I den isolerade arbetsmodellen styr host.json-filen endast händelser som genereras av Functions-värdkörningen. Om du inte konfigurerar filtreringsregler i Program.cs kan 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, gäller dessa på samma sätt endast för kod i projektet. Plattformen behöver även utlösar- och bindningskonfiguration, 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å.

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.

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öra i processen till att köra i en isolerad arbetsprocess måste du ändra värdet för FUNCTIONS_WORKER_RUNTIME till "dotnet-isolated".

host.json fil

Inga ändringar krävs i host.json filen. Men om din Application Insights-konfiguration i den här filen kommer från ditt in-processmodellprojekt kanske du vill göra andra ändringar i Program.cs-filen. 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 .

Ändringar i klassnamn

Vissa nyckelklasser har ändrat namn mellan versioner. 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:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (attribut) Function (attribut) Function (attribut)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (med hjälp av ASP.NET Core-integrering)
IActionResult HttpResponseData HttpResponseData, IActionResult (med hjälp av ASP.NET Core-integrering)
FunctionsStartup (attribut) Använder Program.cs i stället Använder Program.cs i stället

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 Brytande ändringar mellan 3.x och 4.x för andra ändringar som du kan behöva göra i projektet.

JSON-serialisering

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

Application Insights-loggnivåer och filtrering

Loggar kan skickas till Application Insights från både Functions-värdmiljön och koden i projektet. Med host.json kan du konfigurera regler för värdloggning, men för att styra loggar som kommer från koden 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

Skillnaderna mellan processbaserad och isolerad arbetsprocess kan ses i HTTP-utlösta funktioner. HTTP-utlösarmallen för version 3.x (pågående) ser ut som följande exempel:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

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

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

HTTP-utlösarmallen för den migrerade versionen ser 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. Uppdatera appens Azure Functions-tilläggspaket till 2.x eller senare. Mer information finns i icke-bakåtkompatibla ändringar.

  1. Om det behövs går du till en av de Java-versioner som stöds på version 4.x.

  2. Uppdatera appens POM.xml fil för att ändra FUNCTIONS_EXTENSION_VERSION inställningen till ~4, som i följande exempel:

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. Om det behövs går du till en av de Node.js versioner som stöds på version 4.x.
  1. Ta tillfället i akt att uppgradera till PowerShell 7.2, vilket rekommenderas. Mer information finns i PowerShell-versioner.
  1. Om du använder Python 3.6 går du till en av de versioner som stöds.

Kör validatorn före uppgraderingen

I Azure Functions finns en verifierare som hjälper dig att identifiera potentiella problem innan du migrerar funktionsappen till 4.x. Så här kör du validatorn före uppgraderingen:

  1. Gå till funktionsappen i Azure Portal.

  2. Öppna sidan Diagnostisera och lösa problem.

  3. I Funktionsappdiagnostik börjar du Functions 4.x Pre-Upgrade Validator skriva och väljer det sedan i listan.

  4. När valideringen är klar granskar du rekommendationerna och åtgärdar eventuella problem i din app. Om du behöver göra ändringar i appen kontrollerar du ändringarna mot version 4.x av Functions-körningen, antingen lokalt med Azure Functions Core Tools v4 eller med hjälp av ett mellanlagringsfack.

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 slots och sedan publicera om ditt applikationsprojekt. Du kan också minimera stilleståndstiden i din app och förenkla återställningen genom att uppdatera med hjälp av slots.

Uppdatera utan fack

Det enklaste sättet att uppdatera till v4.x är att ställa in programinställningen FUNCTIONS_EXTENSION_VERSION på i funktionsappen ~4 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 på Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körtiden.

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

  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 på Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körtiden.

    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 slottet med den nya inställningen till produktion och samtidigt återställa versionsinställningen i staging-slot.

    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 att ha WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 endast i staging under en växling tar bort inställningen FUNCTIONS_EXTENSION_VERSION i staging. Utan versionsinställningen är din plats i ett dåligt skick. Om du uppdaterar versionen i staging-slotten direkt efter växlingen bör slotten återgå till ett bra tillstånd, och du kan återställa dina ändringar om det behövs. Men en tillbakadragning av swapen kräver också att du direkt tar bort WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 från produktionen innan den återgår till den ursprungliga konfigurationen för att undvika samma fel i produktionen som upptäckts i förstadiet. 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 ställts in för båda platserna.

  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 på Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körtiden.

    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

Brytande ändringar mellan 3.x och 4.x

Följande är viktiga brytande ändringar att vara medveten om innan du uppgraderar en 3.x-app till 4.x, inklusive brytande ändringar som är specifika för språket. En fullständig lista finns i Azure Functions GitHub-ärenden märkta Icke-bakåtkompatibel ändring: Godkänd.

Om du inte ser programmeringsspråket väljer du det överst på sidan.

Körtid

  • Azure Functions-proxyservrar är en äldre funktion för version 1.x till 3.x av Azure Functions-körningen. Stöd för Functions-proxyservrar kan återaktiveras i version 4.x så att du kan uppdatera funktionsapparna till den senaste körningsversionen. Så snart som möjligt bör du i stället byta till att integrera dina funktionsappar med Azure API Management. Med API Management kan du dra nytta av en mer komplett uppsättning funktioner för att definiera, skydda, hantera och tjäna pengar på dina Functions-baserade API:er. Mer information finns i API Management-integrering. Information om hur du återaktiverar stöd för proxyservrar i Functions version 4.x finns i Återaktivera proxyservrar i Functions v4.x.

  • Loggning till Azure Storage med AzureWebJobsDashboard stöds inte längre i 4.x. Du bör i stället använda Application Insights. (#1923)

  • Azure Functions 4.x tillämpar nu lägsta versionskrav för tillägg. Uppdatera till den senaste versionen av berörda tillägg. För icke-.NET-språk uppdatera till tilläggspaket av version 2.x eller senare. (#1987)

  • Standard och maximala tidsgränser tillämpas nu i 4.x för funktionsappar som körs på Linux i en förbrukningsplan. (#1915)

  • Azure Functions 4.x använder Azure.Identity och Azure.Security.KeyVault.Secrets för Key Vault-providern och har föråldrat användningen av Microsoft.Azure.KeyVault. Mer information om hur du konfigurerar inställningar för funktionsappar finns i key vault-alternativet i Hantera nyckellagring. (#2048)

  • Funktionsappar som delar lagringskonton startar nu inte när deras värd-ID är desamma. Mer information finns i Överväganden för värd-ID. (#2049)

  • Använd enkel klassladdare i Java 11. (#1997)

  • Stoppa laddningen av jar-filer i Java 8. (#1991)

  • Node.js versionerna 10 och 12 stöds inte i Azure Functions 4.x. (#1999)

  • Utdataserialisering i Node.js appar uppdaterades för att hantera tidigare inkonsekvenser. (#2007)

  • Standardantalet för trådar har uppdaterats. Funktioner som inte är trådsäkra eller har hög minnesanvändning kan påverkas. (#1962)

  • Python 3.6 stöds inte i Azure Functions 4.x. (#1999)

  • Delad minnesöverföring är aktiverat som standard. (#1973)

  • Standardantalet för trådar har uppdaterats. Funktioner som inte är trådsäkra eller har hög minnesanvändning kan påverkas. (#1962)

Nästa steg

Läs mer om Functions-versioner