Migrera appar från Azure Functions version 1.x till version 4.x
Viktigt!
Java stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din Java-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.
Viktigt!
TypeScript stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din TypeScript-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.
Viktigt!
PowerShell stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera din PowerShell-app från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.
Viktigt!
Python stöds inte av version 1.x av Azure Functions-körningen. Du kanske i stället vill migrera python-appen från version 3.x till version 4.x. Om du migrerar en version 1.x-funktionsapp väljer du antingen C# eller JavaScript ovan.
Viktigt!
Supporten upphör för version 1.x av Azure Functions-körningen den 14 september 2026. Vi rekommenderar starkt att du migrerar dina appar till version 4.x genom att följa anvisningarna i den här artikeln.
Den här artikeln beskriver hur du migrerar funktionsappen på ett säkert sätt och kör version 4.x av Functions-körningen. Eftersom instruktionerna för projektmigrering är språkberoende måste du välja utvecklingsspråk från väljaren överst i artikeln.
Om du kör version 1.x av körningen i Azure Stack Hub läser du Överväganden för Azure Stack Hub först.
Identifiera funktionsappar som ska migreras
Använd följande PowerShell-skript för att generera en lista över funktionsappar i din prenumeration som för närvarande är målversion 1.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 '*1*')
{
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
}
}
$AppInfo
Välj din .NET-målversion
I version 1.x av Functions-körningen riktar sig C#-funktionsappen mot .NET Framework.
När du migrerar funktionsappen har du möjlighet att välja målversionen av .NET. Du kan uppdatera C#-projektet till någon av följande versioner av .NET som stöds av Functions version 4.x:
.NET-version | Versionstyp för .NET Official Support Policy | Funktionsprocessmodell1,2 |
---|---|---|
.NET 9 | Förhandsversion3 | Isolerad arbetsmodell |
.NET 8 | LTS (support upphör 10 november 2026) | Isolerad arbetsmodell, Processmodell2 |
.NET 6 | LTS (support upphör 12 november 2024) | Isolerad arbetsmodell, Processmodell2 |
.NET Framework 4.8 | Se princip | Isolerad arbetsmodell |
1 Den isolerade arbetsmodellen stöder versioner av .NET (Long Term Support) och Standard Term Support (STS) samt .NET Framework. Den processbaserade modellen stöder endast LTS-versioner av .NET, som slutar med .NET 8. En fullständig funktionsjämförelse och funktionsjämförelse mellan de två modellerna finns i Skillnader mellan processer och isolera arbetsprocess .NET Azure Functions.
2 Supporten upphör för den pågående modellen den 10 november 2026. Mer information finns i det här supportmeddelandet. Om du vill ha fortsatt fullständigt stöd bör du migrera dina appar till den isolerade arbetsmodellen.
3 Se Förhandsversioner av .NET i den isolerade arbetsmodellen för mer information om support, aktuella begränsningar och instruktioner för att använda förhandsversionen.
Dricks
Såvida inte appen är beroende av ett bibliotek eller API som endast är tillgängligt för .NET Framework rekommenderar vi att du uppdaterar till .NET 8 på den isolerade arbetsmodellen. Många appar på .NET Framework-målversion 1.x beror bara på att det var det som var tillgängligt när de skapades. Ytterligare funktioner är tillgängliga för nyare versioner av .NET, och om din app inte tvingas stanna kvar i .NET Framework på grund av ett beroende bör du rikta in dig på en senare version. .NET 8 är den fullständigt släppta versionen med det längsta supportfönstret från .NET.
Även om du kan välja att i stället använda den processbaserade modellen rekommenderas detta inte om det kan undvikas. Supporten upphör för den pågående modellen den 10 november 2026, så du måste gå över till den isolerade arbetsmodellen innan dess. Om du migrerar till version 4.x minskar den totala ansträngningen som krävs, och den isolerade arbetsmodellen ger appen ytterligare fördelar, inklusive möjligheten att enklare rikta in sig på framtida versioner av .NET. Om du flyttar till den isolerade arbetsmodellen kan .NET Upgrade Assistant också hantera många av de nödvändiga kodändringarna åt dig.
Den här guiden innehåller inte några specifika exempel för .NET 6. Om du behöver rikta in dig på den versionen kan du anpassa .NET 8-exemplen.
Förbereda för migrering
Om du inte redan har gjort det kan du identifiera listan över appar som måste migreras i din aktuella Azure-prenumeration med hjälp av Azure PowerShell.
Innan du migrerar en app till version 4.x av Functions-körningen bör du utföra följande uppgifter:
- Granska listan över beteendeändringar efter version 1.x. Migrering från version 1.x till version 4.x kan också påverka bindningar.
- Slutför stegen i Migrera ditt lokala projekt för att migrera ditt lokala projekt till version 4.x.
- När du har migrerat projektet testar du appen lokalt med version 4.x av Azure Functions Core Tools.
- Uppdatera funktionsappen i Azure till den nya versionen. Om du behöver minimera stilleståndstiden bör du överväga att använda ett mellanlagringsfack för att testa och verifiera din migrerade app i Azure på den nya körningsversionen. Du kan sedan distribuera din app med de uppdaterade versionsinställningarna till produktionsplatsen. Mer information finns i Uppdatera med hjälp av platser.
- Publicera ditt migrerade projekt till den uppdaterade funktionsappen.
När du använder Visual Studio för att publicera ett version 4.x-projekt till en befintlig funktionsapp i en lägre version uppmanas du att låta Visual Studio uppdatera funktionsappen till version 4.x under distributionen. Den här uppdateringen använder samma process som definierats i Uppdatera utan fack.
Migrera ditt lokala projekt
I följande avsnitt beskrivs de uppdateringar som du måste göra i C#-projektfilerna för att kunna köras på en av de versioner av .NET som stöds i Functions version 4.x. De uppdateringar som visas är de som är gemensamma för de flesta projekt. Din projektkod kan kräva uppdateringar som inte nämns i den här artikeln, särskilt när du använder anpassade NuGet-paket.
Om du migrerar en C#-funktionsapp från version 1.x till version 4.x av Functions-körningen måste du göra ändringar i projektkoden. Många av dessa ändringar är ett resultat av ändringar i C#-språket och .NET-API:er.
Välj den flik som matchar målversionen av .NET och önskad processmodell (pågående eller isolerad arbetsprocess).
Dricks
Om du flyttar till en LTS- eller STS-version av .NET med hjälp av den isolerade arbetsmodellen kan .NET Upgrade Assistant användas för att automatiskt göra många av de ändringar som nämns i följande avsnitt.
Projektfil
Följande exempel är en .csproj
projektfil som körs på version 1.x:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
Använd någon av följande procedurer för att uppdatera XML-filen så att den körs i Functions version 4.x:
De här stegen förutsätter ett lokalt C#-projekt, och om din app i stället använder C#-skript (.csx
filer) bör du konvertera till projektmodellen innan du fortsätter.
Följande ändringar krävs i .csproj
XML-projektfilen:
Ange värdet
PropertyGroup
för .TargetFramework
tillnet8.0
.Ange värdet
PropertyGroup
för .AzureFunctionsVersion
tillv4
.Lägg till följande
OutputType
element iPropertyGroup
:<OutputType>Exe</OutputType>
ItemGroup
I .PackageReference
ersätter du paketreferensen tillMicrosoft.NET.Sdk.Functions
med följande referenser:<FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
Anteckna eventuella referenser till andra paket i
Microsoft.Azure.WebJobs.*
namnrymderna. Du ersätter dessa paket i ett senare steg.Lägg till följande nya
ItemGroup
:<ItemGroup> <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/> </ItemGroup>
När du har genomfört de här ändringarna bör ditt uppdaterade projekt se ut som i följande exempel:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<RootNamespace>My.Namespace</RootNamespace>
<OutputType>Exe</OutputType>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
<!-- Other packages may also be in this list -->
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>
</Project>
Paket- och namnområdesändringar
Baserat på den modell som du migrerar till kan du behöva uppdatera eller ändra paketen som dina programreferenser refererar till. När du antar målpaketen måste du uppdatera namnområdet för att använda -instruktioner och vissa typer som du refererar till. Du kan se effekten av dessa namnområdesändringar på using
-instruktioner i http-utlösarmallsexemplen senare i den här artikeln.
Om du inte redan har gjort det uppdaterar du projektet så att det refererar till de senaste stabila versionerna av:
Beroende på vilka utlösare och bindningar som appen använder kan din app behöva referera till en annan uppsättning paket. I följande tabell visas ersättningarna för några av de vanligaste tilläggen:
Scenario | Ändringar i paketreferenser |
---|---|
Timerutlösare | Lägg till Microsoft.Azure.Functions.Worker.Extensions.Timer |
Lagringsbindningar | ReplaceMicrosoft.Azure.WebJobs.Extensions.Storage med Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues och Microsoft.Azure.Functions.Worker.Extensions.Tables |
Blobbindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
Köbindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.Storage.Queues med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
Tabellbindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.Tables med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.Tables |
Cosmos DB-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.CosmosDB och/eller Microsoft.Azure.WebJobs.Extensions.DocumentDB med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.CosmosDB |
Service Bus-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.ServiceBus med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
Event Hubs-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.EventHubs med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
Event Grid-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.EventGrid med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
SignalR Service-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.SignalRService med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
Bestående funktioner | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.DurableTask med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
Bestående funktioner (SQL-lagringsprovider) |
Ersätt referenser tillMicrosoft.DurableTask.SqlServer.AzureFunctions med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
Bestående funktioner (Netherite Storage-provider) |
Ersätt referenser tillMicrosoft.Azure.DurableTask.Netherite.AzureFunctions med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
SendGrid-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.SendGrid med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
Kafka-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.Kafka med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.Kafka |
RabbitMQ-bindningar | Ersätt referenser tillMicrosoft.Azure.WebJobs.Extensions.RabbitMQ med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
Beroendeinmatning och startkonfiguration |
Ta bort referenser tillMicrosoft.Azure.Functions.Extensions (Den isolerade arbetsmodellen tillhandahåller den här funktionen som standard.) |
Se Bindningar som stöds för en fullständig lista över tillägg att överväga och läs dokumentationen för varje tillägg för fullständiga installationsinstruktioner för den isolerade processmodellen. Se till att installera den senaste stabila versionen av alla paket som du riktar in dig på.
Dricks
Eventuella ändringar av tilläggsversioner under den här processen kan kräva att du även uppdaterar host.json
filen. Läs dokumentationen för varje tillägg som du använder.
Service Bus-tillägget har till exempel icke-bakåtkompatibla ändringar i strukturen mellan versionerna 4.x och 5.x. Mer information finns i Azure Service Bus-bindningar för Azure Functions.
Ditt isolerade arbetsmodellprogram bör inte referera till några paket i Microsoft.Azure.WebJobs.*
namnrymderna eller Microsoft.Azure.Functions.Extensions
. Om du har några återstående referenser till dessa bör de tas bort.
Dricks
Din app kan också vara beroende av Azure SDK-typer, antingen som en del av dina utlösare och bindningar eller som ett fristående beroende. Du bör också ta tillfället i akt att uppdatera dessa. De senaste versionerna av Functions-tilläggen fungerar med de senaste versionerna av Azure SDK för .NET, nästan alla paket som är formuläret Azure.*
.
Bindningarna Notification Hubs och Mobile Apps stöds endast i version 1.x av körningen. När du uppgraderar till version 4.x av körningen måste du ta bort dessa bindningar till förmån för att arbeta med dessa tjänster direkt med sina SDK:er.
Program.cs fil
I de flesta fall kräver migrering att du lägger till följande program.cs fil i projektet:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
var host = new HostBuilder()
.ConfigureFunctionsWebApplication()
.ConfigureServices(services => {
services.AddApplicationInsightsTelemetryWorkerService();
services.ConfigureFunctionsApplicationInsights();
})
.Build();
host.Run();
Det här exemplet omfattar ASP.NET Core-integrering för att förbättra prestanda och tillhandahålla en välbekant programmeringsmodell när din app använder HTTP-utlösare. Om du inte tänker använda HTTP-utlösare kan du ersätta anropet till ConfigureFunctionsWebApplication
med ett anrop till ConfigureFunctionsWorkerDefaults
. Om du gör det kan du ta bort referensen till Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore
från projektfilen. Men för bästa prestanda, även för funktioner med andra utlösartyper, bör du behålla FrameworkReference
till ASP.NET Core.
Filen Program.cs
ersätter alla filer som har FunctionsStartup
attributet, vilket vanligtvis är en Startup.cs
fil. På platser där koden FunctionsStartup
refererar IFunctionsHostBuilder.Services
till kan du i stället lägga till instruktioner i .ConfigureServices()
-metoden HostBuilder
i i .Program.cs
Mer information om hur du arbetar med Program.cs
finns i Start-up and configuration in the isolated worker model guide (Start-up and configuration in the isolated worker model guide).
Standardexemplen Program.cs
ovan är installation av Application Insights-integrering för den isolerade arbetsmodellen. I måste Program.cs
du även konfigurera loggfiltrering som ska gälla för loggar som kommer från kod i projektet. I den isolerade arbetsmodellen host.json
styr filen endast händelser som genereras av Functions-värdkörningen. Om du inte konfigurerar filtreringsregler i Program.cs
kan du se skillnader i loggnivåerna för olika kategorier i telemetrin.
Även om du kan registrera anpassade konfigurationskällor som en del av HostBuilder
, bör du tänka på att dessa på samma sätt endast gäller för kod i projektet. Utlösar- och bindningskonfiguration krävs också av plattformen, och detta bör tillhandahållas via funktionerna för programinställningar, Key Vault-referenser eller appkonfigurationsreferenser .
När du har flyttat allt från alla befintliga FunctionsStartup
till Program.cs
filen kan du ta bort FunctionsStartup
attributet och den klass som det tillämpades på.
host.json fil
Inställningar i host.json-filen gäller på funktionsappsnivå, både lokalt och i Azure. I version 1.x är din host.json fil tom eller innehåller vissa inställningar som gäller för alla funktioner i funktionsappen. Mer information finns i Host.json v1. Om din host.json-fil har inställningsvärden kan du granska host.json v2-format för eventuella ändringar.
Om du vill köra version 4.x måste du lägga till "version": "2.0"
den host.json filen. Du bör också överväga att lägga logging
till i konfigurationen, som i följande exempel:
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
},
"enableLiveMetricsFilters": true
}
}
}
Filen host.json
styr endast loggning från Functions-värdkörningen, och i den isolerade arbetsmodellen kommer vissa av dessa loggar direkt från ditt program, vilket ger dig mer kontroll. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .
local.settings.json fil
Filen local.settings.json används bara när den körs lokalt. Mer information finns i Filen Lokala inställningar. I version 1.x har local.settings.json-filen bara två obligatoriska värden:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
}
}
När du migrerar till version 4.x kontrollerar du att filen local.settings.json har minst följande element:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Kommentar
När du migrerar från att köras i processen till att köras i en isolerad arbetsprocess måste du ändra FUNCTIONS_WORKER_RUNTIME
värdet till "dotnet-isolerad".
Ändringar i klassnamn
Vissa nyckelklasser ändrade namn mellan version 1.x och version 4.x. Dessa ändringar beror antingen på ändringar i .NET-API:er eller på skillnader mellan processprocess och isolerad arbetsprocess. Följande tabell anger viktiga .NET-klasser som används av Functions som kan ändras vid migrering:
Version 1.x | .NET 8 |
---|---|
FunctionName (attribut) |
Function (attribut) |
TraceWriter |
ILogger<T> , ILogger |
HttpRequestMessage |
HttpRequestData , HttpRequest (med hjälp av ASP.NET Core-integrering) |
HttpResponseMessage |
HttpResponseData , IActionResult (med hjälp av ASP.NET Core-integrering) |
Det kan också finnas skillnader i klassnamn i bindningar. Mer information finns i referensartiklarna för de specifika bindningarna.
Andra kodändringar
I det här avsnittet beskrivs andra kodändringar som du bör tänka på när du arbetar med migreringen. Dessa ändringar behövs inte av alla program, men du bör utvärdera om några är relevanta för dina scenarier. Kontrollera beteendeändringar efter version 1.x för ytterligare ändringar som du kan behöva göra i projektet.
JSON-serialisering
Som standard använder System.Text.Json
den isolerade arbetsmodellen för JSON-serialisering. Om du vill anpassa serialiseraralternativ eller växla till JSON.NET (Newtonsoft.Json
) kan du läsa de här anvisningarna.
Application Insights-loggnivåer och filtrering
Loggar kan skickas till Application Insights från både Functions-värdkörningen och koden i projektet. Gör host.json
att du kan konfigurera regler för värdloggning, men för att styra loggar som kommer från din kod måste du konfigurera filtreringsregler som en del av din Program.cs
. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .
HTTP-utlösarmall
De flesta kodändringarna mellan version 1.x och version 4.x kan ses i HTTP-utlösta funktioner. HTTP-utlösarmallen för version 1.x ser ut som i följande exempel:
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static async Task<HttpResponseMessage>
Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post",
Route = null)]HttpRequestMessage req, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
// parse query parameter
string name = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
if (name == null)
{
// Get request body
dynamic data = await req.Content.ReadAsAsync<object>();
name = data?.name;
}
return name == null
? req.CreateResponse(HttpStatusCode.BadRequest,
"Please pass a name on the query string or in the request body")
: req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
}
}
}
I version 4.x ser HTTP-utlösarmallen ut som i följande exempel:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace Company.Function
{
public class HttpTriggerCSharp
{
private readonly ILogger<HttpTriggerCSharp> _logger;
public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
{
_logger = logger;
}
[Function("HttpTriggerCSharp")]
public IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
{
_logger.LogInformation("C# HTTP trigger function processed a request.");
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
}
}
Så här uppdaterar du projektet till Azure Functions 4.x:
Uppdatera din lokala installation av Azure Functions Core Tools till version 4.x.
Flytta till någon av de Node.js versioner som stöds på version 4.x.
Lägg till både
version
ochextensionBundle
element i host.json, så att det ser ut som i följande exempel:{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[3.3.0, 4.0.0)" } }
Elementet
extensionBundle
krävs eftersom bindningar bevaras som externa paket efter version 1.x. Mer information finns i Tilläggspaket.Uppdatera local.settings.json-filen så att den har minst följande element:
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "node" } }
Inställningen
AzureWebJobsStorage
kan vara antingen Azurite Storage-emulatorn eller ett faktiskt Azure-lagringskonto. Mer information finns i Lokal lagringsemulator.
Uppdatera funktionsappen i Azure
Du måste uppdatera körningen av funktionsappens värd i Azure till version 4.x innan du publicerar det migrerade projektet. Körningsversionen som används av Functions-värden styrs av programinställningen FUNCTIONS_EXTENSION_VERSION
, men i vissa fall måste även andra inställningar uppdateras. Både kodändringar och ändringar i programinställningarna kräver att funktionsappen startas om.
Det enklaste sättet är att uppdatera utan platser och sedan publicera om ditt appprojekt. Du kan också minimera stilleståndstiden i din app och förenkla återställningen genom att uppdatera med hjälp av fack.
Uppdatera utan fack
Det enklaste sättet att uppdatera till v4.x är att ställa in programinställningen ~4
på i funktionsappen FUNCTIONS_EXTENSION_VERSION
i Azure. Du måste följa en annan procedur på en plats med platser.
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
Du måste också ange en annan inställning som skiljer sig mellan Windows och Linux.
När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 krävs för funktionsappar på alla språk som körs i Windows.
I det här exemplet ersätter du <APP_NAME>
med namnet på din funktionsapp och <RESOURCE_GROUP_NAME>
med namnet på resursgruppen.
Nu kan du publicera om ditt appprojekt som har migrerats för att köras på version 4.x.
Uppdatera med fack
Att använda distributionsplatser är ett bra sätt att uppdatera funktionsappen till v4.x-körningen från en tidigare version. Genom att använda ett mellanlagringsfack kan du köra appen på den nya körningsversionen på mellanlagringsplatsen och växla till produktion efter verifiering. Fack ger också ett sätt att minimera stilleståndstiden under uppdateringen. Om du behöver minimera stilleståndstiden följer du stegen i Uppdatering av minsta stilleståndstid.
När du har verifierat din app i det uppdaterade facket kan du växla appen och de nya versionsinställningarna till produktion. Den här växlingen kräver inställning WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
i produktionsplatsen. Hur du lägger till den här inställningen påverkar hur lång stilleståndstid som krävs för uppdateringen.
Standarduppdatering
Om din fackaktiverade funktionsapp kan hantera stilleståndstiden för en fullständig omstart kan du uppdatera WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
inställningen direkt i produktionsfacket. Eftersom en ändring av den här inställningen direkt i produktionsplatsen orsakar en omstart som påverkar tillgängligheten bör du överväga att göra den här ändringen i en tid med minskad trafik. Du kan sedan växla i den uppdaterade versionen från mellanlagringsplatsen.
Update-AzFunctionAppSetting
PowerShell-cmdleten stöder för närvarande inte fack. Du måste använda Azure CLI eller Azure Portal.
Använd följande kommando för att ange
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
i produktionsplatsen:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
I det här exemplet ersätter du
<APP_NAME>
med namnet på din funktionsapp och<RESOURCE_GROUP_NAME>
med namnet på resursgruppen. Det här kommandot gör att appen som körs i produktionsfacket startas om.Använd följande kommando för att också ange
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
i mellanlagringsplatsen:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Använd följande kommando för att ändra
FUNCTIONS_EXTENSION_VERSION
och uppdatera mellanlagringsplatsen till den nya körningsversionen:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Version 4.x av Functions-körningen kräver .NET 6 i Windows. I Linux måste .NET-appar också uppdateras till .NET 6. Använd följande kommando så att körningen kan köras på .NET 6:
När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 krävs för funktionsappar på alla språk som körs i Windows.
I det här exemplet ersätter du
<APP_NAME>
med namnet på din funktionsapp och<RESOURCE_GROUP_NAME>
med namnet på resursgruppen.Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.
Bekräfta att funktionsappen körs korrekt i den uppdaterade mellanlagringsmiljön innan du byter.
Använd följande kommando för att växla den uppdaterade mellanlagringsplatsen till produktion:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Minsta stilleståndstidsuppdatering
För att minimera stilleståndstiden i produktionsappen WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
kan du växla inställningen från mellanlagringsplatsen till produktion. Därefter kan du växla i den uppdaterade versionen från ett förvärmt mellanlagringsfack.
Använd följande kommando för att ange
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
i mellanlagringsplatsen:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Använd följande kommandon för att växla facket med den nya inställningen till produktion och samtidigt återställa versionsinställningen i mellanlagringsplatsen.
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Du kan se fel från mellanlagringsplatsen under tiden mellan växlingen och körningsversionen som återställs vid mellanlagring. Det här felet kan inträffa eftersom
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
endast mellanlagring under en växling tar bort inställningen i mellanlagringenFUNCTIONS_EXTENSION_VERSION
. Utan versionsinställningen är ditt fack i ett felaktigt tillstånd. Om du uppdaterar versionen i mellanlagringsplatsen direkt efter växlingen bör platsen återgå till ett bra tillstånd och du anropar återställ dina ändringar om det behövs. Men en återställning av växlingen kräver också att du tar bortWEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
direkt från produktionen innan växlingen tillbaka för att förhindra samma fel i produktionen som visas i mellanlagringen. Den här ändringen i produktionsinställningen skulle sedan orsaka en omstart.Använd följande kommando för att ange
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
igen i mellanlagringsplatsen:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Nu har
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
båda platserna angetts.Använd följande kommando för att ändra
FUNCTIONS_EXTENSION_VERSION
och uppdatera mellanlagringsplatsen till den nya körningsversionen:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Version 4.x av Functions-körningen kräver .NET 6 i Windows. I Linux måste .NET-appar också uppdateras till .NET 6. Använd följande kommando så att körningen kan köras på .NET 6:
När du kör i Windows måste du också aktivera .NET 6.0, vilket krävs av version 4.x av körningen.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 krävs för funktionsappar på alla språk som körs i Windows.
I det här exemplet ersätter du
<APP_NAME>
med namnet på din funktionsapp och<RESOURCE_GROUP_NAME>
med namnet på resursgruppen.Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.
Bekräfta att funktionsappen körs korrekt i den uppdaterade mellanlagringsmiljön innan du byter.
Använd följande kommando för att växla den uppdaterade och förinställda mellanlagringsplatsen till produktion:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Beteendeändringar efter version 1.x
I det här avsnittet beskrivs ändringar som gjorts efter version 1.x i både utlösar- och bindningsbeteenden samt i funktioner och beteenden i kärnfunktioner.
Ändringar i utlösare och bindningar
Från och med version 2.x måste du installera tilläggen för specifika utlösare och bindningar som används av funktionerna i appen. Det enda undantaget för dessa HTTP- och timerutlösare, som inte kräver något tillägg. Mer information finns i Registrera och installera bindningstillägg.
Det finns också några ändringar i function.json eller attribut för funktionen mellan versioner. Till exempel är egenskapen Event Hubs path
nu eventHubName
. Se den befintliga bindningstabellen för länkar till dokumentationen för varje bindning.
Ändringar i funktioner och funktioner
Några funktioner har tagits bort, uppdaterats eller ersatts efter version 1.x. Det här avsnittet beskriver de ändringar du ser i senare versioner efter att ha använt version 1.x.
I version 2.x gjordes följande ändringar:
Nycklar för att anropa HTTP-slutpunkter lagras alltid krypterade i Azure Blob Storage. I version 1.x lagrades nycklar som standard i Azure Files. När du migrerar en app från version 1.x till version 2.x återställs befintliga hemligheter som finns i Azure Files.
Version 2.x-körningen innehåller inte inbyggt stöd för webhook-leverantörer. Den här ändringen gjordes för att förbättra prestandan. Du kan fortfarande använda HTTP-utlösare som slutpunkter för webhooks.
För att förbättra övervakningen ersätts instrumentpanelen WebJobs i portalen, som använde
AzureWebJobsDashboard
inställningen med Azure Application Insights, som använder inställningenAPPINSIGHTS_INSTRUMENTATIONKEY
. Mer information finns i Övervaka Azure Functions.Alla funktioner i en funktionsapp måste dela samma språk. När du skapar en funktionsapp måste du välja en körningsstack för appen. Körningsstacken
FUNCTIONS_WORKER_RUNTIME
anges av värdet i programinställningarna. Det här kravet har lagts till för att förbättra fotavtryck och starttid. När du utvecklar lokalt måste du även inkludera den här inställningen i filen local.settings.json.Standardtimeouten för funktioner i en App Service-plan ändras till 30 minuter. Du kan manuellt ändra tidsgränsen tillbaka till obegränsad med hjälp av inställningen functionTimeout i host.json.
HTTP-samtidighetsbegränsningar implementeras som standard för funktioner i förbrukningsplanen, med standardvärdet 100 samtidiga begäranden per instans. Du kan ändra det här beteendet i
maxConcurrentRequests
inställningen i host.json-filen.På grund av .NET Core-begränsningar har stöd för F#-skriptfunktioner (
.fsx
filer) tagits bort. Kompilerade F#-funktioner (.fs) stöds fortfarande.URL-formatet för Event Grid-utlösarwebbhooks har ändrats för att följa det här mönstret:
https://{app}/runtime/webhooks/{triggerName}
.Namnen på vissa fördefinierade anpassade mått ändrades efter version 1.x.
Duration
ersattes medMaxDurationMs
,MinDurationMs
ochAvgDurationMs
.Success Rate
har också bytt namn tillSuccess Rate
.
Överväganden för Azure Stack Hub
App Service på Azure Stack Hub stöder inte version 4.x av Azure Functions. När du planerar en migrering av version 1.x i Azure Stack Hub kan du välja något av följande alternativ:
- Migrera till version 4.x som finns i det offentliga molnet Azure Functions med hjälp av anvisningarna i den här artikeln. I stället för att uppgradera din befintliga app skapar du en ny app med version 4.x och distribuerar sedan det ändrade projektet till den.
- Växla till WebJobs som finns i en App Service-plan i Azure Stack Hub.