Dela via

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

  • Artikel

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

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 funktionsjämförelse och funktionsjämförelse mellan de två modellerna finns i Skillnader mellan processer och isolera arbetsprocess .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.

Dricks

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 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 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 icke-bakåtkompatibla ä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 platser.
  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äljer du 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).

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

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

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

host.json fil

Inga ändringar krävs i host.json filen. Men om Application Insights-konfigurationen i den här filen från ditt processmodellprojekt kanske du vill göra ytterligare ä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. Se till att kontrollera Icke-bakåtkompatibla ändringar mellan 3.x och 4.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

Skillnaderna mellan processbaserad och isolerad arbetsprocess kan ses i HTTP-utlösta funktioner. HTTP-utlösarmallen för version 3.x (pågår) ser ut som i 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 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 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 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

Icke-bakåtkompatibla ändringar mellan 3.x och 4.x

Följande är viktiga icke-bakåtkompatibla ändringar att känna till innan du uppgraderar en 3.x-app till 4.x, inklusive språkspecifika icke-bakåtkompatibla ändringar. En fullständig lista finns i Azure Functions GitHub-problem med etiketten Icke-bakåtkompatibel ändring: Godkänd.

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

Körmiljö

  • 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 non-.NET språk uppdaterar du till tilläggspaketet 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 enklassinläsare i Java 11. (#1997)

  • Sluta läsa in arbetsburkar 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