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 8 | LTS (einde van ondersteuning 10 november 2026) | Geïsoleerde werkrolmodel, In-process model2 |
.NET 6 | LTS (einde van ondersteuning 12 november 2024) | 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 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 6. Als u deze versie wilt toepassen, kunt u de .NET 8-voorbeelden 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:
- Bekijk de lijst met belangrijke wijzigingen tussen 3.x en 4.x.
- Voer de stappen uit in Uw lokale project migreren om uw lokale project te migreren naar versie 4.x.
- Nadat u uw project hebt gemigreerd, test u de app volledig lokaal met versie 4.x van de Azure Functions Core Tools.
- Voer de validator vóór de upgrade uit op de app die wordt gehost in Azure en los eventuele geïdentificeerde problemen op.
- 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.
- 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:
Stel de waarde van
PropertyGroup
.TargetFramework
aannet8.0
.Stel de waarde van
PropertyGroup
.AzureFunctionsVersion
aanv4
.Voeg het volgende element toe aan het
PropertyGroup
volgendeOutputType
element:<OutputType>Exe</OutputType>
In de
ItemGroup
.PackageReference
vervang de pakketverwijzing doorMicrosoft.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.Voeg de volgende nieuwe
ItemGroup
toe:<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 | ReplaceMicrosoft.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 naarMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
Wachtrijbindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.Storage.Queues met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
Tabelbindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.Tables met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.Tables |
Cosmos DB-bindingen | Verwijzingen vervangen naarMicrosoft.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 | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.ServiceBus met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
Event Hubs-bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.EventHubs met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
Event Grid-bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.EventGrid met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
SignalR Service-bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.SignalRService met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
Durable Functions | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.DurableTask met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
Durable Functions (SQL Storage-provider) |
Verwijzingen vervangen naarMicrosoft.DurableTask.SqlServer.AzureFunctions met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
Durable Functions (Netherite-opslagprovider) |
Verwijzingen vervangen naarMicrosoft.Azure.DurableTask.Netherite.AzureFunctions met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
SendGrid-bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.SendGrid met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
Kafka-bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.Kafka met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.Kafka |
RabbitMQ bindingen | Verwijzingen vervangen naarMicrosoft.Azure.WebJobs.Extensions.RabbitMQ met de nieuwste versie van Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
Afhankelijkheidsinjectie en opstartconfiguratie |
Verwijzingen verwijderen naarMicrosoft.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 HostBuilder
Program.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.cs
U 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.cs
configureert, 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 HostBuilder
configuratie, 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:
Werk uw lokale installatie van Azure Functions Core Tools bij naar versie 4.x.
Werk de Azure Functions-extensiesbundel van uw app bij naar 2.x of hoger. Zie belangrijke wijzigingen voor meer informatie.
Ga indien nodig naar een van de Java-versies die worden ondersteund op versie 4.x.
Werk het bestand van
POM.xml
de app bij om deFUNCTIONS_EXTENSION_VERSION
instelling te~4
wijzigen 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>
- Ga indien nodig naar een van de Node.js versies die worden ondersteund op versie 4.x.
- Maak van deze gelegenheid gebruik om een upgrade uit te voeren naar PowerShell 7.2. Dit wordt aanbevolen. Zie PowerShell-versies voor meer informatie.
- 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:
Navigeer in Azure Portal naar uw functie-app.
Open de pagina Problemen vaststellen en oplossen .
Begin in Functie-app diagnostische gegevens te typen
Functions 4.x Pre-Upgrade Validator
en kies deze vervolgens in de lijst.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.
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.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>
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>
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.Als voor uw codeproject updates zijn vereist om te worden uitgevoerd op versie 4.x, implementeert u deze updates nu in de staging-site.
Controleer of uw functie-app correct wordt uitgevoerd in de bijgewerkte faseringsomgeving voordat u wisselt.
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.
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>
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 deFUNCTIONS_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 verwijderenWEBSITE_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.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.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>
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.Als voor uw codeproject updates zijn vereist om te worden uitgevoerd op versie 4.x, implementeert u deze updates nu in de staging-site.
Controleer of uw functie-app correct wordt uitgevoerd in de bijgewerkte faseringsomgeving voordat u wisselt.
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
enAzure.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)
- Het standaardaantal threads is bijgewerkt. Functies die niet thread-veilig zijn of een hoog geheugengebruik hebben, kunnen worden beïnvloed. (#1962)