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

  • Artikel

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,3
.NET 82 LTS Geïsoleerde werkrolmodel
.NET 7 STS (einde van ondersteuning 14 mei 2024) Geïsoleerde werkrolmodel
.NET 6 LTS (einde van ondersteuning 12 november 2024) Geïsoleerde werkrolmodel,
In-process model3
.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. Zie Verschillen tussen proces- en isoleerproces .NET Azure Functions voor een volledige functie en functionaliteitsvergelijking tussen de twee modellen.

2 .NET 8 wordt nog niet ondersteund in het procesmodel, hoewel deze beschikbaar is in het geïsoleerde werkrolmodel. Zie het bericht Azure Functions Roadmap Update voor meer informatie over .NET 8-abonnementen, inclusief toekomstige opties voor het in-process model.

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

Tip

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, wordt dit niet aanbevolen als dit kan worden vermeden. 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 7 of .NET 6 op het geïsoleerde werkrolmodel. Als u deze versies wilt toepassen, kunt u de voorbeelden van het geïsoleerde werkrolmodel van .NET 8 aanpassen.

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

Tip

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 en 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 .csproj XML-projectbestand:

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

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

  3. Voeg het volgende element toe aan het PropertyGroupvolgende OutputType element:

    <OutputType>Exe</OutputType>

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

      <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 de pakketten waarnaar u migreert mogelijk bijwerken of wijzigen. Wanneer u de doelpakketten gebruikt, moet u vervolgens de naamruimte bijwerken van het gebruik van instructies en enkele typen waarnaar u verwijst. U kunt het effect van deze naamruimtewijzigingen zien op using instructies in de voorbeelden van http-triggersjablonen verderop 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:

Scenario Wijzigingen in pakketverwijzingen
Timertrigger Toevoegen
Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage-bindingen Replace
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 Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Wachtrijbindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabelbindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Tables
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.CosmosDB
Of
Microsoft.Azure.WebJobs.Extensions.DocumentDB
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.ServiceBus
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.EventHubs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.EventGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.SignalRService
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.DurableTask
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(SQL Storage-provider)		 Verwijzingen vervangen naar
Microsoft.DurableTask.SqlServer.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Netherite-opslagprovider)		 Verwijzingen vervangen naar
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.SendGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Kafka
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ bindingen Verwijzingen vervangen naar
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.

Tip

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.

Tip

Uw app kan ook afhankelijk zijn van Azure SDK-typen, hetzij als onderdeel van uw triggers en bindingen of als zelfstandige afhankelijkheid. U kunt deze ook bijwerken. 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.

bestand Program.cs

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 vervangen door ConfigureFunctionsWebApplication 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, zelfs voor functies met andere triggertypen, moet u echter de FrameworkReference to-ASP.NET Core behouden.

Het Program.cs bestand vervangt elk bestand dat het FunctionsStartup kenmerk heeft. Dit is meestal een Startup.cs bestand. Op plaatsen waarnaar uw FunctionsStartup code zou verwijzen IFunctionsHostBuilder.Services, kunt u in plaats daarvan instructies toevoegen binnen de .ConfigureServices() methode van de in uw HostBuilderProgram.cs. Voor meer informatie over het werken met Program.cs, raadpleegt u Opstart- en configuratiehandleiding in de handleiding voor geïsoleerde werkrollen.

De bovenstaande standaardvoorbeelden Program.cs omvatten het instellen van Application Insights-integratie voor het geïsoleerde werkrolmodel. Program.csU moet 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 Program.csconfigureert, 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, moet u er rekening mee houden dat deze op dezelfde manier van toepassing zijn op code in uw project. De trigger- en bindingsconfiguratie is ook nodig voor het platform. 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-proces naar uitvoering in een geïsoleerd werkproces, moet u de FUNCTIONS_WORKER_RUNTIME waarde wijzigen in '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 aanvullende 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 in 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. Controleer de wijzigingen die fouten veroorzaken tussen 3.x en 4.x voor aanvullende wijzigingen die u mogelijk moet aanbrengen in uw project.

JSON-serialisatie

Standaard wordt het geïsoleerde werkrolmodel gebruikt System.Text.Json voor JSON-serialisatie. Als u serialisatieopties wilt aanpassen of wilt overschakelen naar JSON.NET (Newtonsoft.Json), raadpleegt u deze instructies.

Application Insights-logboekniveaus en -filters

Logboeken kunnen vanuit zowel de Functions-hostruntime als code in uw project naar Application Insights worden verzonden. Hiermee host.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 het proces en het geïsoleerde werkproces 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 bestand van POM.xml de app bij om de FUNCTIONS_EXTENSION_VERSION instelling te ~4wijzigen in, 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. Begin in Functie-app diagnostische gegevens te typen Functions 4.x Pre-Upgrade Validator en kies deze vervolgens in 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 sites

Het gebruik van implementatiesites is een goede manier om uw functie-app bij te werken naar de v4.x-runtime van 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 instelling WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 in de productiesite vereist. Hoe u deze instelling toevoegt, is van invloed op de hoeveelheid downtime die nodig is voor de update.

Standard-update

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 wisselen in de bijgewerkte versie van de staging-site.

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 in de productiesite in te stellen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 :

    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-site in te stellen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS :

    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 de staging-site te wijzigen FUNCTIONS_EXTENSION_VERSION en 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 voor uw codeproject updates zijn vereist om te worden uitgevoerd op versie 4.x, implementeert u deze updates nu in de staging-site.

  6. Controleer of uw functie-app correct wordt uitgevoerd in de bijgewerkte faseringsomgeving voordat u wisselt.

  7. Gebruik de volgende opdracht om de bijgewerkte staging-site om te wisselen naar productie:

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

Minimale downtime-update

Als u de downtime in uw productie-app wilt minimaliseren, kunt u de WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS instelling van de staging-site omzetten in productie. Daarna kunt u wisselen in de bijgewerkte versie van een vooraf inwarmende staging-site.

  1. Gebruik de volgende opdracht om in de staging-site in te stellen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 :

    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 site om te wisselen met de nieuwe instelling in productie en herstel tegelijkertijd de versie-instelling in de staging-site.

    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-site tijdens de tijd tussen de wissel en de runtimeversie die wordt hersteld tijdens fasering. 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. Voor elke terugdraaibewerking van de swap moet u echter ook rechtstreeks uit de productie verwijderen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 voordat de wissel teruggaat om te voorkomen dat dezelfde fouten in de productie in de fasering worden gezien. Deze wijziging in de productie-instelling veroorzaakt dan opnieuw opstarten.

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

    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 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 beide sleuven ingesteld.

  4. Gebruik de volgende opdracht om de staging-site te wijzigen FUNCTIONS_EXTENSION_VERSION en 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 voor uw codeproject updates zijn vereist om te worden uitgevoerd op versie 4.x, implementeert u deze updates nu in de staging-site.

  7. Controleer of uw functie-app correct wordt uitgevoerd in de bijgewerkte faseringsomgeving voordat u wisselt.

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

    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 belangrijke wijzigingen die belangrijk zijn om rekening mee te houden voordat u een 3.x-app bijwerken naar 4.x, inclusief taalspecifieke wijzigingen die fouten veroorzaken. 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.

Runtime

  • 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 non-.NET talen werkt u bij naar extensiebundelversie 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 Geheime opslagplaatsen 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 in-process en geïsoleerde apps van .NET 6.

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

  • EnableEnhancedScopes is standaard ingeschakeld. (#1954)

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

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

  • Stop met het laden van werkrol-JAR's 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