Delen via

Apps migreren van Azure Functions versie 3.x naar versie 4.x

Azure Functions versie 4.x is zeer achterwaarts compatibel met versie 3.x. De meeste apps moeten veilig worden gemigreerd naar 4.x zonder dat er aanzienlijke codewijzigingen nodig zijn. Zie het overzicht van runtimeversies van Azure Functions voor meer informatie over runtimeversies van Functions.

Belangrijk

Vanaf 13 december 2022 hebben functie-apps die worden uitgevoerd op versie 2.x en 3.x van de Azure Functions-runtime het einde van de uitgebreide ondersteuning bereikt. Zie Buiten gebruik gestelde versies voor meer informatie.

In dit artikel wordt uitgelegd hoe u uw functie-app veilig kunt migreren om uit te voeren op versie 4.x van de Functions-runtime. Omdat de instructies voor projectmigratie afhankelijk zijn van taal, moet u uw ontwikkeltaal kiezen in de selector bovenaan het artikel.

Functie-apps identificeren die moeten worden gemigreerd

Gebruik het volgende PowerShell-script om een lijst met functie-apps te genereren in uw abonnement die momenteel gericht zijn op versie 2.x of 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

Kies uw .NET-doelversie

Op versie 3.x van de Functions-runtime is uw C#-functie-app gericht op .NET Core 3.1 met behulp van het in-procesmodel of .NET 5 met behulp van het geïsoleerde werkrolmodel.

Wanneer u uw functie-app migreert, hebt u de mogelijkheid om de doelversie van .NET te kiezen. U kunt uw C#-project bijwerken naar een van de volgende versies van .NET die worden ondersteund door Functions versie 4.x:

.NET-versie Releasetype voor .NET Official Support Policy Functions-procesmodel1,2
.NET 9 STS (einde van ondersteuning 12 mei 2026) Geïsoleerde werkrolmodel
.NET 8 LTS (einde van ondersteuning 10 november 2026) Geïsoleerde werkrolmodel,
In-process model2
.NET Framework 4.8 Beleid weergeven Geïsoleerde werkrolmodel

1 Het geïsoleerde werkrolmodel ondersteunt LTS-versies (Long Term Support) en STS-versies (Standard Term Support) van .NET, evenals .NET Framework. Het in-process model ondersteunt alleen LTS-releases van .NET, eindigend op .NET 8. Zie Verschillen tussen proces- en isoleerproces .NET Azure Functions voor een volledige functie en functionaliteitsvergelijking tussen de twee modellen.

2 Ondersteuning eindigt op het procesmodel op 10 november 2026. Zie deze ondersteuningsaankondiging voor meer informatie. Voor voortdurende volledige ondersteuning moet u uw apps migreren naar het geïsoleerde werkrolmodel.

Suggestie

U wordt aangeraden bij te werken naar .NET 8 op het geïsoleerde werkrolmodel. .NET 8 is de volledig uitgebrachte versie met het langste ondersteuningsvenster van .NET.

Hoewel u ervoor kunt kiezen om in plaats daarvan het in-procesmodel te gebruiken, raden we deze aanpak niet aan als u dit kunt voorkomen. De ondersteuning voor het in-procesmodel eindigt op 10 november 2026, dus u moet eerst naar het geïsoleerde werkrolmodel gaan. Als u dit doet terwijl u migreert naar versie 4.x, neemt de totale inspanning af en biedt het geïsoleerde werkrolmodel uw app extra voordelen, waaronder de mogelijkheid om zich gemakkelijker te richten op toekomstige versies van .NET. Als u overstapt op het geïsoleerde werkrolmodel, kan de .NET-upgradeassistent ook veel van de benodigde codewijzigingen voor u afhandelen.

Deze handleiding bevat geen specifieke voorbeelden voor .NET 9. Als u deze versie wilt toepassen, kunt u de .NET 8-voorbeelden aanpassen voor het geïsoleerde werkrolmodel.

Voorbereiden op migratie

Als u dat nog niet hebt gedaan, identificeert u de lijst met apps die moeten worden gemigreerd in uw huidige Azure-abonnement met behulp van Azure PowerShell.

Voordat u een app migreert naar versie 4.x van de Functions-runtime, moet u de volgende taken uitvoeren:

  1. Bekijk de lijst met belangrijke wijzigingen tussen 3.x en 4.x.
  2. Voer de stappen uit in Uw lokale project migreren om uw lokale project te migreren naar versie 4.x.
  3. Nadat u uw project hebt gemigreerd, test u de app volledig lokaal met versie 4.x van de Azure Functions Core Tools.
  4. Voer de validator vóór de upgrade uit op de app die wordt gehost in Azure en los eventuele geïdentificeerde problemen op.
  5. Werk uw functie-app in Azure bij naar de nieuwe versie. Als u downtime wilt minimaliseren, kunt u overwegen om een staging-site te gebruiken om uw gemigreerde app in Azure te testen en te controleren op de nieuwe runtimeversie. Vervolgens kunt u uw app implementeren met de bijgewerkte versie-instellingen naar de productiesite. Zie Update met behulp van slots voor meer informatie.
  6. Publiceer uw gemigreerde project naar de bijgewerkte functie-app.

Wanneer u Visual Studio gebruikt om een versie 4.x-project te publiceren naar een bestaande functie-app met een lagere versie, wordt u gevraagd om Visual Studio de functie-app tijdens de implementatie bij te werken naar versie 4.x. Deze update maakt gebruik van hetzelfde proces dat is gedefinieerd in Update zonder sleuven.

Uw lokale project migreren

Upgrade-instructies zijn taalafhankelijk. Als u uw taal niet ziet, kiest u deze in de selector bovenaan het artikel.

Kies het tabblad dat overeenkomt met uw doelversie van .NET en het gewenste procesmodel (in-process of geïsoleerd werkproces).

Suggestie

Als u overstapt op een LTS- of STS-versie van .NET met behulp van het geïsoleerde werkrolmodel, kan de .NET-upgradeassistent worden gebruikt om automatisch veel van de wijzigingen in de volgende secties aan te brengen.

Projectbestand

Het volgende voorbeeld is een .csproj projectbestand dat gebruikmaakt van .NET Core 3.1 op versie 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>

Gebruik een van de volgende procedures om dit XML-bestand bij te werken voor uitvoering in Functions versie 4.x:

Bij deze stappen wordt uitgegaan van een lokaal C#-project; als uw app in plaats daarvan C#-script (.csx-bestanden ) gebruikt, moet u converteren naar het projectmodel voordat u doorgaat.

De volgende wijzigingen zijn vereist in het XML-projectbestand .csproj :

  1. Stel de waarde van PropertyGroup. TargetFramework aan net8.0.

  2. Stel de waarde van PropertyGroup. AzureFunctionsVersion aan v4.

  3. Voeg het volgende OutputType-element toe aan de PropertyGroup.

    <OutputType>Exe</OutputType>

  4. In de ItemGroup.Maak een lijst en vervang de pakketverwijzing PackageReference door de volgende verwijzingen: Microsoft.NET.Sdk.Functions

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

    Noteer eventuele verwijzingen naar andere pakketten in de Microsoft.Azure.WebJobs.* naamruimten. U vervangt deze pakketten in een latere stap.

  5. Voeg de volgende nieuwe ItemGrouptoe:

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

Nadat u deze wijzigingen hebt aangebracht, ziet het bijgewerkte project eruit als in het volgende voorbeeld:

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

Wijzigingen in pakket- en naamruimte

Op basis van het model waarnaar u migreert, moet u mogelijk de pakketten bijwerken of wijzigen waarnaar uw applicatie verwijst. Wanneer u de doelpakketten gebruikt, moet u vervolgens de naamruimte van de gebruikinstructies en enkele typen waar u naar verwijst bijwerken. U kunt het effect van deze naamruimtewijzigingen zien op using instructies in de voorbeelden van HTTP-triggersjablonen later in dit artikel.

Als u dat nog niet hebt gedaan, werkt u uw project bij om te verwijzen naar de nieuwste stabiele versies van:

Afhankelijk van de triggers en bindingen die uw app gebruikt, moet uw app mogelijk verwijzen naar een andere set pakketten. In de volgende tabel ziet u de vervangingen voor enkele van de meest gebruikte extensies:

Scenariobeschrijving Wijzigingen in pakketverwijzingen
Timer-trigger Toevoegen
Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage-bindingen Vervangen
Microsoft.Azure.WebJobs.Extensions.Storage
wordt uitgevoerd met
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues en
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blob-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Koppelingen voor wachtrij Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabelbindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.Tables
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.CosmosDB
en/of
Microsoft.Azure.WebJobs.Extensions.DocumentDB
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.ServiceBus
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.EventHubs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.EventGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.SignalRService
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Duurzame Functies Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.DurableTask
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Duurzame Functies
(SQL Storage-provider)		 Vervang verwijzingen door
Microsoft.DurableTask.SqlServer.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Duurzame Functies
(Netherite-opslagprovider)		 Vervang verwijzingen door
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.SendGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.Kafka
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Afhankelijkheidsinjectie
en opstartconfiguratie		 Verwijzingen verwijderen naar
Microsoft.Azure.Functions.Extensions
(Het geïsoleerde werkrolmodel biedt deze functionaliteit standaard.)

Zie Ondersteunde bindingen voor een volledige lijst met extensies die u kunt overwegen en raadpleeg de documentatie van elke extensie voor volledige installatie-instructies voor het geïsoleerde procesmodel. Zorg ervoor dat u de nieuwste stabiele versie installeert van alle pakketten die u wilt gebruiken.

Suggestie

Voor eventuele wijzigingen in extensieversies tijdens dit proces moet u het host.json bestand mogelijk ook bijwerken. Lees de documentatie van elke extensie die u gebruikt. De Service Bus-extensie heeft bijvoorbeeld belangrijke wijzigingen in de structuur tussen versie 4.x en 5.x. Zie Azure Service Bus-bindingen voor Azure Functions voor meer informatie.

Uw geïsoleerde werkrolmodeltoepassing mag niet verwijzen naar pakketten in de Microsoft.Azure.WebJobs.* naamruimten of Microsoft.Azure.Functions.Extensions. Als u nog verwijzingen naar deze referenties hebt, moeten ze worden verwijderd.

Suggestie

Uw app kan ook afhankelijk zijn van Azure SDK-typen, hetzij als onderdeel van uw triggers en bindingen of als zelfstandige afhankelijkheid. U zou deze gelegenheid moeten benutten om deze ook bij te werken. De nieuwste versies van de Functions-extensies werken met de nieuwste versies van de Azure SDK voor .NET, bijna alle pakketten waarvoor het formulier Azure.*is.

Program.cs-bestand

Wanneer u migreert om uit te voeren in een geïsoleerd werkproces, moet u het volgende program.cs bestand toevoegen aan uw project:

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

Dit voorbeeld omvat ASP.NET Core-integratie om de prestaties te verbeteren en een vertrouwd programmeermodel te bieden wanneer uw app HTTP-triggers gebruikt. Als u geen HTTP-triggers wilt gebruiken, kunt u de aanroep ConfigureFunctionsWebApplication vervangen door een aanroep naar ConfigureFunctionsWorkerDefaults. Als u dit doet, kunt u de verwijzing Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore uit het projectbestand verwijderen. Voor de beste prestaties moet u voor functies met andere triggertypen echter FrameworkReference bij ASP.NET Core houden.

Het bestand Program.cs vervangt elk bestand dat het FunctionsStartup kenmerk heeft. Dit is meestal een Startup.cs bestand. Op plaatsen waar uw FunctionsStartup code IFunctionsHostBuilder.Services zou verwijzen, kun je in plaats daarvan instructies toevoegen in de .ConfigureServices() methode van de HostBuilder in je Program.cs. Zie de handleiding voor het opstarten en configureren van het geïsoleerde werkmodel voor meer informatie over het werken met Program.cs.

De standaard Program.cs voorbeelden die eerder zijn beschreven, omvatten de installatie van Application Insights. In uw Program.cs moet u ook logboekfilters configureren die van toepassing moeten zijn op logboeken die afkomstig zijn van code in uw project. In het geïsoleerde werkrolmodel beheert het host.json bestand alleen gebeurtenissen die worden verzonden door de Functions-hostruntime. Als u geen filterregels configureert in Program.cs, ziet u mogelijk verschillen in de logboekniveaus die aanwezig zijn voor verschillende categorieën in uw telemetrie.

Hoewel u aangepaste configuratiebronnen kunt registreren als onderdeel van de HostBuilderconfiguratie, zijn deze ook alleen van toepassing op code in uw project. Het platform heeft ook trigger- en bindingsconfiguratie nodig. Dit moet worden opgegeven via de functies voor toepassingsinstellingen, Key Vault-verwijzingen of App Configuration-verwijzingen .

Nadat u alles van een bestaand FunctionsStartup naar het Program.cs-bestand hebt verplaatst, kunt u het FunctionsStartup kenmerk en de klasse waarop het is toegepast, verwijderen.

local.settings.json-bestand

Het local.settings.json-bestand wordt alleen gebruikt wanneer het lokaal wordt uitgevoerd. Zie het bestand Met lokale instellingen voor meer informatie.

Wanneer u migreert naar versie 4.x, moet u ervoor zorgen dat uw local.settings.json bestand ten minste de volgende elementen bevat:

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

Notitie

Wanneer u migreert van in-procesuitvoering naar uitvoering in een geïsoleerd proces, moet u de FUNCTIONS_WORKER_RUNTIME-waarde wijzigen naar "dotnet-isolated".

host.json bestand

Er zijn geen wijzigingen in het host.json bestand vereist. Als uw Application Insights-configuratie in dit bestand echter vanuit uw in-process modelproject wordt uitgevoerd, wilt u mogelijk andere wijzigingen aanbrengen in uw Program.cs bestand. Het host.json bestand beheert alleen logboekregistratie van de Functions-hostruntime en in het geïsoleerde werkrolmodel zijn sommige van deze logboeken rechtstreeks afkomstig van uw toepassing, zodat u meer controle hebt. Zie Logboekniveaus beheren in het geïsoleerde werkrolmodel voor meer informatie over het filteren van deze logboeken.

Wijzigingen in klassenaam

Sommige sleutelklassen hebben namen tussen versies gewijzigd. Deze wijzigingen zijn het gevolg van wijzigingen in .NET-API's of in verschillen tussen het proces en het geïsoleerde werkproces. De volgende tabel geeft de belangrijkste .NET-klassen aan die worden gebruikt door Functions die kunnen worden gewijzigd tijdens de migratie:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (kenmerk) Function (kenmerk) Function (kenmerk)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (met ASP.NET Core-integratie)
IActionResult HttpResponseData HttpResponseData, IActionResult (met ASP.NET Core-integratie)
FunctionsStartup (kenmerk) Gebruikt Program.cs in plaats daarvan Gebruikt Program.cs in plaats daarvan

Er zijn mogelijk ook verschillen in klassenamen tussen bindingen. Zie de naslagartikelen voor de specifieke bindingen voor meer informatie.

Andere codewijzigingen

In deze sectie worden andere codewijzigingen gemarkeerd die u kunt overwegen tijdens het uitvoeren van de migratie. Deze wijzigingen zijn niet nodig voor alle toepassingen, maar u moet evalueren of deze relevant zijn voor uw scenario's. Zorg ervoor dat u ingrijpende veranderingen tussen 3.x en 4.x controleert voor andere wijzigingen die u mogelijk in uw project moet aanbrengen.

JSON-serialisatie

Het geïsoleerde werkrolmodel maakt standaard gebruik van System.Text.Json voor JSON-serialisatie. Zie Aanpassen van JSON-serialisatie als u serialisatieopties wilt aanpassen of wilt overschakelen naar JSON.NET (Newtonsoft.Json).

Application Insights-logboekniveaus en -filteren

Logboeken kunnen vanuit zowel de Functions-hostruntime als code in uw project naar Application Insights worden verzonden. Met dehost.json kunt u regels voor hostlogboekregistratie configureren, maar om logboeken te beheren die afkomstig zijn van uw code, moet u filterregels configureren als onderdeel van uw Program.cs. Zie Logboekniveaus beheren in het geïsoleerde werkrolmodel voor meer informatie over het filteren van deze logboeken.

HTTP-triggersjabloon

De verschillen tussen in-proces en geïsoleerde werkprocessen zijn te zien in door HTTP geactiveerde functies. De HTTP-triggersjabloon voor versie 3.x (in-proces) ziet er als volgt uit:

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

De HTTP-triggersjabloon voor de gemigreerde versie ziet er als volgt uit:

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

Uw project bijwerken naar Azure Functions 4.x:

  1. Werk uw lokale installatie van Azure Functions Core Tools bij naar versie 4.x.

  2. Werk de Azure Functions-extensiesbundel van uw app bij naar 2.x of hoger. Zie belangrijke wijzigingen voor meer informatie.

  1. Ga indien nodig naar een van de Java-versies die worden ondersteund op versie 4.x.

  2. Werk het POM.xml-bestand van de app bij om de FUNCTIONS_EXTENSION_VERSION-instelling te wijzigen naar ~4, zoals in het volgende voorbeeld:

    <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. Ga indien nodig naar een van de Node.js versies die worden ondersteund op versie 4.x.
  1. Maak van deze gelegenheid gebruik om een upgrade uit te voeren naar PowerShell 7.2. Dit wordt aanbevolen. Zie PowerShell-versies voor meer informatie.
  1. Als u Python 3.6 gebruikt, gaat u naar een van de ondersteunde versies.

De validator vóór de upgrade uitvoeren

Azure Functions biedt een validatie vóór de upgrade waarmee u mogelijke problemen kunt identificeren bij het migreren van uw functie-app naar 4.x. De validator vóór de upgrade uitvoeren:

  1. Navigeer in Azure Portal naar uw functie-app.

  2. Open de pagina Problemen vaststellen en oplossen .

  3. In Functie-app diagnostiek, begin met typen Functions 4.x Pre-Upgrade Validator en kies het vervolgens uit de lijst.

  4. Nadat de validatie is voltooid, bekijkt u de aanbevelingen en kunt u eventuele problemen in uw app oplossen. Als u wijzigingen wilt aanbrengen in uw app, moet u de wijzigingen valideren op basis van versie 4.x van de Functions-runtime, lokaal met behulp van Azure Functions Core Tools v4 of met behulp van een staging-site.

Uw functie-app bijwerken in Azure

U moet de runtime van de host van de functie-app in Azure bijwerken naar versie 4.x voordat u het gemigreerde project publiceert. De runtimeversie die door de Functions-host wordt gebruikt, wordt beheerd door de FUNCTIONS_EXTENSION_VERSION toepassingsinstelling, maar in sommige gevallen moeten andere instellingen ook worden bijgewerkt. Voor zowel codewijzigingen als wijzigingen in toepassingsinstellingen moet uw functie-app opnieuw worden opgestart.

De eenvoudigste manier is om zonder sites bij te werken en vervolgens uw app-project opnieuw te publiceren. U kunt ook de downtime in uw app minimaliseren en terugdraaien vereenvoudigen door het bijwerken met behulp van sites.

Bijwerken zonder sites

De eenvoudigste manier om bij te werken naar v4.x is door de FUNCTIONS_EXTENSION_VERSION toepassingsinstelling ~4 in te stellen op uw functie-app in Azure. U moet een andere procedure volgen op een site met sites.

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

U moet ook een andere instelling instellen, die verschilt tussen Windows en Linux.

Wanneer u windows gebruikt, moet u ook .NET 6.0 inschakelen. Dit is vereist voor versie 4.x van de runtime.

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

.NET 6 is vereist voor functie-apps in elke taal die wordt uitgevoerd in Windows.

Vervang in dit voorbeeld door <APP_NAME> de naam van uw functie-app en <RESOURCE_GROUP_NAME> door de naam van de resourcegroep.

U kunt uw app-project dat is gemigreerd, nu opnieuw publiceren om te worden uitgevoerd op versie 4.x.

Bijwerken met behulp van tijdvakken

Het gebruik van implementatieslots is een goede manier om uw functie-app bij te werken naar de v4.x-runtime vanuit een vorige versie. Met behulp van een staging-site kunt u uw app uitvoeren op de nieuwe runtimeversie in de staging-site en na verificatie overschakelen naar productie. Sites bieden ook een manier om downtime tijdens de update te minimaliseren. Als u downtime wilt minimaliseren, volgt u de stappen in Minimale downtime-update.

Nadat u uw app in de bijgewerkte site hebt geverifieerd, kunt u de app en de nieuwe versie-instellingen in productie wisselen. Voor deze wissel is het instellen van WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 in de productieslot vereist. Hoe u deze instelling toevoegt, is van invloed op de hoeveelheid downtime die nodig is voor de update.

Standaardupdate

Als uw functie-app met sleuf de downtime van een volledig opnieuw opstarten kan afhandelen, kunt u de WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS instelling rechtstreeks in de productiesite bijwerken. Omdat het rechtstreeks wijzigen van deze instelling in de productiesite een herstart veroorzaakt die van invloed is op de beschikbaarheid, kunt u overwegen deze wijziging uit te voeren op een moment van minder verkeer. U kunt vervolgens de bijgewerkte versie vanuit de staging-slot inwisselen.

De Update-AzFunctionAppSetting PowerShell-cmdlet biedt momenteel geen ondersteuning voor sites. U moet Azure CLI of Azure Portal gebruiken.

  1. Gebruik de volgende opdracht om WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 in het productieslot in te stellen:

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

    Vervang in dit voorbeeld door <APP_NAME> de naam van uw functie-app en <RESOURCE_GROUP_NAME> door de naam van de resourcegroep. Met deze opdracht wordt de app die in de productiesite wordt uitgevoerd, opnieuw gestart.

  2. Gebruik de volgende opdracht om ook in de staging-slot WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS in te stellen:

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

  3. Gebruik de volgende opdracht om FUNCTIONS_EXTENSION_VERSION te wijzigen en de staging-slot bij te werken naar de nieuwe runtimeversie.

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

  4. Voor versie 4.x van de Functions-runtime is .NET 6 in Windows vereist. In Linux moeten .NET-apps ook worden bijgewerkt naar .NET 6. Gebruik de volgende opdracht zodat de runtime kan worden uitgevoerd op .NET 6:

    Wanneer u windows gebruikt, moet u ook .NET 6.0 inschakelen. Dit is vereist voor versie 4.x van de runtime.

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

    .NET 6 is vereist voor functie-apps in elke taal die wordt uitgevoerd in Windows.

    Vervang in dit voorbeeld door <APP_NAME> de naam van uw functie-app en <RESOURCE_GROUP_NAME> door de naam van de resourcegroep.

  5. Als uw codeproject updates nodig heeft om te werken op versie 4.x, implementeert u deze updates nu in de staging-slot.

  6. Controleer of uw functie toepassing correct wordt uitgevoerd in de onlangs bijgewerkte staging-omgeving voordat u omwisselt.

  7. Gebruik de volgende opdracht om de bijgewerkte staging-slot om te wisselen met productie:

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

Minimale uitvaltijd-update

Als u de downtime in uw productie-app wilt minimaliseren, kunt u de WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS instelling van de staging-slot naar productie draaien. Daarna kunt u de bijgewerkte versie omwisselen van een voorgewarmde staging-slot.

  1. Gebruik de volgende opdracht om WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 in de staging-slot te configureren.

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

  2. Gebruik de volgende opdrachten om de slot te verwisselen met de nieuwe instelling in productie, en herstel tegelijkertijd de versie-instelling in de stageringsslot.

    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>

    Mogelijk ziet u fouten van de staging-slot tijdens de periode tussen de wissel en het moment waarop de runtimeversie wordt hersteld op de staging. Deze fout kan optreden omdat tijdens WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 het wisselen alleen fasering de FUNCTIONS_EXTENSION_VERSION instelling in fasering verwijdert. Zonder de versie-instelling heeft uw site een slechte status. Als u de versie in de staging-site direct na de wissel bijwerkt, wordt de site weer in een goede staat geplaatst en wordt u de wijzigingen teruggedraaid, indien nodig. Echter, bij het terugdraaien van de swap moet u ook eerst WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 direct uit de productie verwijderen voordat de swap wordt teruggedraaid, om te voorkomen dat er dezelfde fouten optreden in de productie als eerder in de testomgeving. Deze wijziging in de productie-instelling zou dan een herstart veroorzaken.

  3. Gebruik de volgende opdracht om WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 opnieuw in te stellen in de staging-omgeving:

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

    Op dit moment zijn beide sleuven WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 ingesteld.

  4. Gebruik de volgende opdracht om FUNCTIONS_EXTENSION_VERSION te wijzigen en de staging-slot bij te werken naar de nieuwe runtimeversie.

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

  5. Voor versie 4.x van de Functions-runtime is .NET 6 in Windows vereist. In Linux moeten .NET-apps ook worden bijgewerkt naar .NET 6. Gebruik de volgende opdracht zodat de runtime kan worden uitgevoerd op .NET 6:

    Wanneer u windows gebruikt, moet u ook .NET 6.0 inschakelen. Dit is vereist voor versie 4.x van de runtime.

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

    .NET 6 is vereist voor functie-apps in elke taal die wordt uitgevoerd in Windows.

    Vervang in dit voorbeeld door <APP_NAME> de naam van uw functie-app en <RESOURCE_GROUP_NAME> door de naam van de resourcegroep.

  6. Als uw codeproject updates nodig heeft om te werken op versie 4.x, implementeert u deze updates nu in de staging-slot.

  7. Controleer of uw functie toepassing correct wordt uitgevoerd in de onlangs bijgewerkte staging-omgeving voordat u omwisselt.

  8. Gebruik de volgende opdracht om de bijgewerkte en voorverwarmde staging-slot naar productie om te zetten:

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

Belangrijke wijzigingen tussen 3.x en 4.x

Hieronder vindt u belangrijke wijzigingen waarmee rekening moet worden gehouden voordat u een 3.x-app bijwerkt naar 4.x, inclusief taalspecifieke breekpunten. Zie Azure Functions GitHub-problemen met het label Belangrijke wijziging: Goedgekeurd voor een volledige lijst.

Als u de programmeertaal niet ziet, selecteert u deze bovenaan de pagina.

Looptijd

  • Azure Functions-proxy's is een verouderde functie voor versies 1.x tot en met 3.x van de Azure Functions-runtime. Ondersteuning voor Functions-proxy's kan opnieuw worden ingeschakeld in versie 4.x, zodat u uw functie-apps kunt bijwerken naar de nieuwste runtimeversie. Zo snel mogelijk moet u overschakelen naar de integratie van uw functie-apps met Azure API Management. Met API Management kunt u profiteren van een uitgebreidere set functies voor het definiëren, beveiligen, beheren en geld verdienen met uw op Functions gebaseerde API's. Zie API Management-integratie voor meer informatie. Zie Proxy's opnieuw inschakelen in Functions versie 4.x voor meer informatie over het opnieuw inschakelen van proxy's in Functions v4.x.

  • Logboekregistratie bij Azure Storage met behulp van AzureWebJobsDashboard wordt niet meer ondersteund in 4.x. U moet in plaats daarvan Application Insights gebruiken. (#1923)

  • Azure Functions 4.x dwingt nu minimale versievereisten af voor extensies. Werk bij naar de nieuwste versie van de betreffende extensies. Voor niet-.NET-talen, werk bij naar extensiebundel versie 2.x of hoger. (#1987)

  • Standaard- en maximale time-outs worden nu afgedwongen in 4.x voor functie-apps die worden uitgevoerd op Linux in een verbruiksabonnement. (#1915)

  • Azure Functions 4.x gebruikt Azure.Identity en Azure.Security.KeyVault.Secrets voor de Key Vault-provider en heeft het gebruik van Microsoft.Azure.KeyVault afgeschaft. Zie de optie Key Vault in Sleutelopslag beheren voor meer informatie over het configureren van instellingen voor functie-apps. (#2048)

  • Functie-apps die opslagaccounts delen, kunnen nu niet worden gestart wanneer hun host-id's hetzelfde zijn. Zie Overwegingen voor host-id's voor meer informatie. (#2049)

  • Azure Functions 4.x ondersteunt nieuwere versies van .NET. Zie Ondersteunde talen in Azure Functions voor een volledige lijst met versies.

  • InvalidHostServicesException is nu een fatale fout. (#2045)

  • EnableEnhancedScopes is standaard ingeschakeld. (#1954)

  • Verwijder HttpClient als een geregistreerde service. (#1911)

  • Gebruik een loader van één klasse in Java 11. (#1997)

  • Stop met het laden van worker jars in Java 8. (#1991)

  • Node.js versies 10 en 12 worden niet ondersteund in Azure Functions 4.x. (#1999)

  • Uitvoerserialisatie in Node.js-apps is bijgewerkt om eerdere inconsistenties te verhelpen. (#2007)

  • Het standaardaantal threads is bijgewerkt. Functies die niet thread-veilig zijn of een hoog geheugengebruik hebben, kunnen worden beïnvloed. (#1962)

  • Python 3.6 wordt niet ondersteund in Azure Functions 4.x. (#1999)

  • Gedeelde geheugenoverdracht is standaard ingeschakeld. (#1973)

  • Het standaardaantal threads is bijgewerkt. Functies die niet thread-veilig zijn of een hoog geheugengebruik hebben, kunnen worden beïnvloed. (#1962)

Volgende stappen

Meer informatie over Functions-versies