Översikt över Azure Functions körningsversioner

Azure Functions stöder för närvarande flera versioner av körningsvärden. I följande tabell beskrivs tillgängliga versioner, deras supportnivå och när de ska användas:

Version Supportnivå Beskrivning
4.x Allmän tillgänglighet (GA) Rekommenderad körningsversion för funktioner på alla språk. Använd den här versionen för att köra C#-funktioner på .NET 6.0, .NET 7.0 och .NET Framework 4.8.
3.x Allmän tillgänglighet (GA) Stöder alla språk. Använd den här versionen för att köra C#-funktioner på .NET Core 3.1 och .NET 5.0.
2.x Allmän tillgänglighet (GA) Stöds för äldre version 2.x-appar. Den här versionen är i underhållsläge, med förbättringar som endast tillhandahålls i senare versioner.
1.x Allmän tillgänglighet (GA) Rekommenderas endast för C#-appar som måste använda .NET Framework och endast stöder utveckling i Azure Portal, Azure Stack Hub-portalen eller lokalt på Windows-datorer. Den här versionen är i underhållsläge, med förbättringar som endast tillhandahålls i senare versioner.

Viktigt

Från och med den 3 december 2022 kan funktionsappar som körs på versionerna 2.x och 3.x av Azure Functions-körningen inte längre stödjas. Innan dess ska du testa, verifiera och migrera dina funktionsappar till version 4.x av Functions-körningen. Mer information finns i Migrera från 3.x till 4.x. Efter tidsgränsen kan funktionsappar skapas och distribueras, och befintliga appar fortsätter att köras. Dina appar är dock inte berättigade till nya funktioner, säkerhetskorrigeringar, prestandaoptimeringar och support förrän du uppgraderar dem till version 4.x.

Upphörande av support för dessa körningsversioner beror på att supporten för .NET Core 3.1 upphör, vilket krävs av dessa äldre körningsversioner. Det här kravet påverkar alla Azure Functions körningsspråk.
Functions version 1.x stöds fortfarande för C#-funktionsappar som kräver .NET Framework. Förhandsversionsstöd är nu tillgängligt i Functions 4.x för att köra C#-funktioner på .NET Framework 4.8.

Den här artikeln beskriver några av skillnaderna mellan dessa versioner, hur du kan skapa varje version och hur du ändrar den version som dina funktioner körs på.

Supportnivåer

Det finns två stödnivåer:

  • Allmänt tillgänglig (GA) – fullständigt stödd och godkänd för produktionsanvändning.
  • Förhandsversion – stöds inte ännu, men förväntas nå GA-status i framtiden.

Språk

Alla funktioner i en funktionsapp måste dela samma språk. Du väljer funktionsspråket i funktionsappen när du skapar appen. Funktionsappens språk underhålls i inställningen FUNCTIONS_WORKER_RUNTIME och bör inte ändras när det finns befintliga funktioner.

Följande tabell anger vilka programmeringsspråk som för närvarande stöds i varje körningsversion.

Språk 1.x 2.x 3.x 4.x
C# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1)
GA (.NET 5.0)
GA (.NET 6.0)
Förhandsversion (.NET 7)
Förhandsversion (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10 & 8) GA (Node.js 14, 12, & 10) GA (Node.js 14)
GA (Node.js 16)
Förhandsversion (Node.js 18)
F# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1) GA (.NET 6.0)
Java Ej tillämpligt GA (Java 8) GA (Java 11 & 8) GA (Java 11 & 8)
PowerShell Ej tillämpligt GA (PowerShell Core 6) GA (PowerShell 7.0 & Core 6) GA (PowerShell 7.0)
GA (PowerShell 7.2)
Python Ej tillämpligt GA (Python 3.7 & 3.6) GA (Python 3.9, 3.8, 3.7, & 3.6) GA (Python 3.9, 3.8, 3.7)
TypeScript2 Ej tillämpligt Allmän tillgänglighet (GA) Allmän tillgänglighet (GA) Allmän tillgänglighet (GA)

1 .NET-klassbiblioteksappar för körningsversion 2.x körs på .NET Core 3.1 i .NET Core 2.x-kompatibilitetsläge. Mer information finns i Överväganden för Functions v2.x.
2 Stöds via transpilering till JavaScript.

Mer information om språkversioner som stöds finns i artikeln om språkspecifika utvecklarguider.
Information om planerade ändringar av språkstöd finns i Azure-översikt.

Köra på en specifik version

Som standard är funktionsappar som skapats i Azure Portal och av Azure CLI inställda på version 4.x. Du kan ändra den här versionen om det behövs. Du kan bara nedgradera körningsversionen till 1.x när du har skapat funktionsappen, men innan du lägger till några funktioner. Att flytta till en senare version tillåts även med appar som har befintliga funktioner. När din app har befintliga funktioner bör du vara medveten om eventuella icke-bakåtkompatibla ändringar mellan versioner innan du flyttar till en senare körningsversion. I följande avsnitt beskrivs icke-bakåtkompatibla ändringar mellan versioner, inklusive språkspecifika icke-bakåtkompatibla ändringar.

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

Innan du gör en ändring i huvudversionen av körningen bör du först testa din befintliga kod på den nya körningsversionen. Du kan kontrollera att appen körs korrekt efter uppgraderingen genom att distribuera till en annan funktionsapp som körs på den senaste huvudversionen. Du kan också verifiera koden lokalt med hjälp av den körningsspecifika versionen av Azure Functions Core Tools, som innehåller Functions-körningen.

Nedgradering till v2.x stöds inte. När det är möjligt bör du alltid köra dina appar på den senaste versionen av Functions-körningen som stöds.

Ändra version av appar i Azure

Versionen av Functions-körningen som används av publicerade appar i Azure styrs av programinställningen FUNCTIONS_EXTENSION_VERSION . Följande viktiga körningsversionsvärden stöds:

Värde Körningsmål
~4 4.x
~3 3.x
~2 2.x
~1 1.x

Viktigt

Ändra inte den här appinställningen godtyckligt eftersom andra appinställningar kan behöva ändras och ändras i funktionskoden. Du bör i stället ändra den här inställningen på fliken Funktionskörningsinställningar i funktionsappen Konfiguration i Azure Portal när du är redo att göra en större versionsuppgradering.

Mer information finns i Så här riktar du dig till Azure Functions körningsversioner.

Fästa på en viss delversion

För att lösa problem som funktionsappen kan ha när den körs på den senaste huvudversionen måste du tillfälligt fästa appen på en viss delversion. Med fästning får du tid att köra appen korrekt på den senaste huvudversionen. Hur du fäster på en delversion skiljer sig mellan Windows och Linux. Mer information finns i Så här riktar du dig till Azure Functions körningsversioner.

Äldre delversioner tas regelbundet bort från Functions. För de senaste nyheterna om Azure Functions versioner, inklusive borttagning av specifika äldre delversioner, övervakar du Azure App Service meddelanden.

Fästa på version ~2.0

.NET-funktionsappar som körs på version 2.x (~2) uppgraderas automatiskt för att köras på .NET Core 3.1, vilket är en långsiktig supportversion av .NET Core 3. Genom att köra dina .NET-funktioner på .NET Core 3.1 kan du dra nytta av de senaste säkerhetsuppdateringarna och produktförbättringarna.

Alla funktionsappar som fästs ~2.0 på fortsätter att köras på .NET Core 2.2, som inte längre får säkerhet och andra uppdateringar. Mer information finns i Överväganden för Functions v2.x.

Lägsta tilläggsversioner

Det finns tekniskt sett ingen korrelation mellan bindningstilläggsversioner och Functions-körningsversionen. Men från och med version 4.x framtvingar Functions-körningen en lägsta version för alla utlösar- och bindningstillägg.

Om du får en varning om att ett paket inte uppfyller en lägsta version som krävs bör du uppdatera NuGet-paketet till den lägsta versionen som vanligt. Lägsta versionskrav för tillägg som används i Functions v4.x finns i den länkade konfigurationsfilen.

För C#-skript uppdaterar du tilläggspaketreferensen i host.json på följande sätt:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Det finns tekniskt sett ingen korrelation mellan tilläggspaketversioner och Functions-körningsversionen. Men från och med version 4.x framtvingar Functions-körningen en lägsta version för tilläggspaket.

Om du får en varning om att tilläggspaketversionen inte uppfyller en lägsta version som krävs uppdaterar du din befintliga tilläggspaketreferens i host.json enligt följande:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Mer information om tilläggspaket finns i Tilläggspaket.

Migrera från 3.x till 4.x

Azure Functions version 4.x är mycket bakåtkompatibel till version 3.x. De flesta appar bör på ett säkert sätt uppgradera till 4.x utan att kräva betydande kodändringar. En uppgradering initieras när du anger appinställningen FUNCTIONS_EXTENSION_VERSION till värdet ~4. För funktionsappar som körs i Windows måste du också ange platsinställningen netFrameworkVersion som mål för .NET 6.

Innan du uppgraderar appen till version 4.x av Functions-körningen bör du utföra följande uppgifter:

Kör föruppgraderingsverifieraren

Azure Functions tillhandahåller en validator före uppgradering som hjälper dig att identifiera potentiella problem när du migrerar funktionsappen till 4.x. Så här kör du föruppgraderingsverifieraren:

  1. I Azure Portal navigerar du till funktionsappen.

  2. Öppna sidan Diagnostisera och lösa problem .

  3. I Funktionsappdiagnostik börjar du Functions 4.x Pre-Upgrade Validator skriva och väljer det i listan.

  4. När valideringen är klar granskar du rekommendationerna och åtgärdar eventuella problem i din app. Om du behöver göra ändringar i appen kontrollerar du ändringarna mot version 4.x av Functions-körningen, antingen lokalt med Azure Functions Core Tools v4 eller med hjälp av ett mellanlagringsfack.

Migrera utan fack

Det enklaste sättet att uppgradera till v4.x är att ställa in programinställningen ~4 på i funktionsappen FUNCTIONS_EXTENSION_VERSION i Azure. När funktionsappen körs i Windows måste du också uppdatera webbplatsinställningen netFrameworkVersion 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>

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>

I de här exemplen ersätter du <APP_NAME> med namnet på din funktionsapp och <RESOURCE_GROUP_NAME> med namnet på resursgruppen.

Migrera med fack

Att använda distributionsfack är ett bra sätt att migrera funktionsappen till v4.x-körningen från en tidigare version. Genom att använda en mellanlagringsplats 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 uppgraderingen. Om du behöver minimera stilleståndstiden följer du stegen i Minsta nedtidsuppgradering.

När du har verifierat din app i den uppgraderade platsen 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 mycket stilleståndstid som krävs för uppgraderingen.

Standarduppgradering

Om din platsaktiverade funktionsapp kan hantera stilleståndstiden för en fullständig omstart kan du uppdatera WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS inställningen direkt i produktionsplatsen. 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 uppgraderade versionen från mellanlagringsplatsen.

Update-AzFunctionAppSetting PowerShell-cmdleten stöder för närvarande inte platser. Du måste använda Azure CLI eller Azure Portal.

  1. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 i produktionsplatsen:

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

    Det här kommandot gör att appen som körs i produktionsplatsen startas om.

  2. Använd följande kommando för att också ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS i mellanlagringsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  3. Använd följande kommando för att ändra FUNCTIONS_EXTENSION_VERSION och uppgradera mellanlagringsplatsen till den nya körningsversionen:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  4. (Endast Windows) För funktionsappar som körs i Windows använder du följande kommando så att körningen kan köras på .NET 6:

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

    Version 4.x av Functions-körningen kräver .NET 6 när den körs i Windows.

  5. Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.

  6. Kontrollera att funktionsappen körs korrekt i den uppgraderade mellanlagringsmiljön innan du byter.

  7. Använd följande kommando för att växla den uppgraderade mellanlagringsplatsen till produktion:

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

Minsta nedtidsuppgradering

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 uppgraderade versionen från ett förvärmt mellanlagringsfack.

  1. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 i mellanlagringsplatsen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  2. Använd följande kommandon för att växla facket med den nya inställningen till produktion och återställ samtidigt 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. Detta kan inträffa eftersom om du bara har WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 mellanlagring under en växling tar bort FUNCTIONS_EXTENSION_VERSION inställningen i mellanlagringen. Utan versionsinställningen är platsen i ett felaktigt tillstånd. Uppdatering av versionen i mellanlagringsplatsen direkt efter växlingen bör försätta platsen i ett bra tillstånd igen och du anropar återställ dina ändringar om det behövs. Men en återställning av växlingen kräver också att du direkt tar bort WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 från produktionen innan växlingen tillbaka för att förhindra samma fel i produktionen som visas i mellanlagringen. Den här ändringen i produktionsinställningen skulle sedan orsaka en omstart.

  3. Använd följande kommando för att ange WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 igen i mellanlagringsplatsen:

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

    Nu har WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 båda platserna angetts.

  4. Använd följande kommando för att ändra FUNCTIONS_EXTENSION_VERSION och uppgradera mellanlagringsplatsen till den nya körningsversionen:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  5. (Endast Windows) För funktionsappar som körs i Windows använder du följande kommando så att körningen kan köras på .NET 6:

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

    Version 4.x av Functions-körningen kräver .NET 6 när den körs i Windows.

  6. Om kodprojektet kräver att uppdateringarna körs på version 4.x distribuerar du uppdateringarna till mellanlagringsplatsen nu.

  7. Kontrollera att funktionsappen körs korrekt i den uppgraderade mellanlagringsmiljön innan du byter.

  8. Använd följande kommando för att växla den uppgraderade och förvärmade mellanlagringsplatsen till produktion:

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

Uppgradera ditt lokala projekt

Uppgraderingsinstruktioner är språkberoende. Om du inte ser ditt språk väljer du det från växlaren överst i artikeln.

Så här uppdaterar du ett C#-klassbiblioteksprojekt till .NET 6 och Azure Functions 4.x:

  1. Uppdatera din lokala installation av Azure Functions Core Tools till version 4.

  2. TargetFramework Uppdatera och AzureFunctionsVersion, enligt följande:

    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    
  3. Uppdatera NuGet-paketen som refereras av din app till de senaste versionerna. Mer information finns i icke-bakåtkompatibla ändringar.
    Specifika paket beror på om dina funktioner körs i processen eller inte.

Så här uppdaterar du projektet till Azure Functions 4.x:

  1. Uppdatera din lokala installation av Azure Functions Core Tools till version 4.x.

  2. Uppdatera appens paket med Azure Functions tillägg till 2.x eller senare. Mer information finns i icke-bakåtkompatibla ändringar.

  1. Om du använder Node.js version 10 eller 12 flyttar du till en av de versioner som stöds.
  1. Om du använder PowerShell Core 6 flyttar du till en av de versioner som stöds.
  1. Om du använder Python 3.6 flyttar du till en av de versioner som stöds.

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

Följande är viktiga icke-bakåtkompatibla ändringar att känna till innan du uppgraderar en 3.x-app till 4.x, inklusive språkspecifika icke-bakåtkompatibla ändringar. En fullständig lista finns i Azure Functions GitHub-problem med etiketten Icke-bakåtkompatibel ändring: Godkänd. Fler ändringar förväntas under förhandsgranskningsperioden. Prenumerera på App Service Meddelanden för uppdateringar.

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

Körning

  • Azure Functions proxyservrar stöds inte längre i 4.x. Du rekommenderas att använda Azure API Management.

  • Loggning till Azure Storage med AzureWebJobsDashboard stöds inte längre i 4.x. Du bör i stället använda Application Insights. (#1923)

  • Azure Functions 4.x tillämpar nu lägsta versionskrav för tillägg. Uppgradera till den senaste versionen av berörda tillägg. Uppgradera till tilläggspaket version 2.x eller senare för non-.NET språk. (#1987)

  • Standard och maximal timeout tillämpas nu i 4.x för funktionsappar som körs på Linux i en förbrukningsplan. (#1915)

  • Azure Functions 4.x använder Azure.Identity och Azure.Security.KeyVault.Secrets för Key Vault-providern och har föråldrat användningen av Microsoft.Azure.KeyVault. Mer information om hur du konfigurerar inställningar för funktionsappar finns i alternativet Key Vault i Hemliga lagringsplatser. (#2048)

  • Funktionsappar som delar lagringskonton startar nu inte när deras värd-ID:n är desamma. Mer information finns i Överväganden för värd-ID. (#2049)

  • Azure Functions 4.x stöder .NET 6 in-process och isolerade appar.

  • InvalidHostServicesException är nu ett allvarligt fel. (#2045)

  • EnableEnhancedScopes är aktiverat som standard. (#1954)

  • Ta bort HttpClient som en registrerad tjänst. (#1911)

  • Använd en klassinläsare i Java 11. (#1997)

  • Sluta läsa in arbetsburkar i Java 8. (#1991)

  • Node.js versionerna 10 och 12 stöds inte i Azure Functions 4.x. (#1999)

  • Utdataserialisering i Node.js appar uppdaterades för att hantera tidigare inkonsekvenser. (#2007)

  • PowerShell 6 stöds inte i Azure Functions 4.x. (#1999)

  • Standardantalet för trådar har uppdaterats. Funktioner som inte är trådsäkra eller har hög minnesanvändning kan påverkas. (#1962)

  • Python 3.6 stöds inte i Azure Functions 4.x. (#1999)

  • Delad minnesöverföring är aktiverat som standard. (#1973)

  • Standardantalet för trådar har uppdaterats. Funktioner som inte är trådsäkra eller har hög minnesanvändning kan påverkas. (#1962)

Migrera från 2.x till 3.x

Azure Functions version 3.x är mycket bakåtkompatibel till version 2.x. Många appar kan på ett säkert sätt uppgradera till 3.x utan några kodändringar. När du flyttar till 3.x uppmuntras du att köra omfattande tester innan du ändrar huvudversionen i produktionsappar.

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

Följande är de språkspecifika ändringar som du bör känna till innan du uppgraderar en 2.x-app till 3.x. Om du inte ser programmeringsspråket väljer du det överst på sidan.

De största skillnaderna mellan versioner när du kör .NET-klassbiblioteksfunktioner är .NET Core-körningen. Functions version 2.x är utformad för att köras på .NET Core 2.2 och version 3.x är utformad för att köras på .NET Core 3.1.

Anteckning

På grund av supportproblem med .NET Core 2.2 körs funktionsappar som är fästa på version 2 (~2) i princip på .NET Core 3.1. Mer information finns i Functions v2.x-kompatibilitetsläge.

  • Utdatabindningar som tilldelats via 1.x context.done eller returvärden fungerar nu på samma sätt som inställningen i 2.x+ context.bindings.

  • Timerutlösarobjektet är camelCase i stället för PascalCase

  • Händelsehubbens utlösta funktioner med dataType binärfil tar emot en matris binary med i stället för string.

  • Nyttolasten för HTTP-begäran kan inte längre nås via context.bindingData.req. Den kan fortfarande nås som en indataparameter, context.req, och i context.bindings.

  • Node.js 8 stöds inte längre och körs inte i 3.x-funktioner.

Migrera från 1.x till senare versioner

Du kan välja att migrera en befintlig app som skrivits för att använda version 1.x runtime för att i stället använda en nyare version. De flesta ändringar du behöver göra är relaterade till ändringar i språkkörningen, till exempel C#-API-ändringar mellan .NET Framework 4.8 och .NET Core. Du måste också se till att koden och biblioteken är kompatibla med den språkkörning du väljer. Se slutligen till att notera eventuella ändringar i utlösare, bindningar och funktioner som är markerade nedan. För bästa migreringsresultat bör du skapa en ny funktionsapp i en ny version och porta din befintliga version 1.x-funktionskod till den nya appen.

Även om det är möjligt att göra en "på plats"-uppgradering genom att manuellt uppdatera appkonfigurationen, innehåller en del icke-bakåtkompatibla ändringar att gå från 1.x till en högre version. I C# ändras till exempel felsökningsobjektet från TraceWriter till ILogger. Genom att skapa ett nytt version 3.x-projekt börjar du med uppdaterade funktioner baserat på den senaste versionen av 3.x-mallar.

Ändringar i utlösare och bindningar efter version 1.x

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 din app. Det enda undantaget för 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 efter version 1.x

Några funktioner har tagits bort, uppdaterats eller ersatts efter version 1.x. Det här avsnittet beskriver de ändringar som visas 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 i Azure Files som standard. När du uppgraderar en app från version 1.x till version 2.x återställs befintliga hemligheter som finns i Azure Files.

  • Version 2.x Runtime 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.

  • Värdkonfigurationsfilen (host.json) ska vara tom eller ha strängen "version": "2.0".

  • För att förbättra övervakningen ersätts webjobs-instrumentpanelen i portalenAzureWebJobsDashboard, som använde inställningen med Azure Application Insights, som använder APPINSIGHTS_INSTRUMENTATIONKEY inställningen. 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 anges av FUNCTIONS_WORKER_RUNTIME värdet i programinställningarna. Det här kravet har lagts till för att förbättra fotavtrycket och starttiden. När du utvecklar lokalt måste du även inkludera den här inställningen i filen local.settings.json.

  • Standardtidsgränsen för funktioner i en App Service plan ändras till 30 minuter. Du kan manuellt ändra tidsgränsen tillbaka till obegränsad genom att använda 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 filen host.json.

  • 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 så att det följer det här mönstret: https://{app}/runtime/webhooks/{triggerName}.

Lokalt utvecklade programversioner

Du kan göra följande uppdateringar för funktionsappar för att lokalt ändra målversionerna.

Visual Studio Runtime-versioner

I Visual Studio väljer du körningsversionen när du skapar ett projekt. Azure Functions verktyg för Visual Studio stöder de tre större körningsversionerna. Rätt version används vid felsökning och publicering baserat på projektinställningar. Versionsinställningarna definieras i .csproj filen i följande egenskaper:

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Du kan också välja net6.0, net7.0eller net48 som målramverk om du använder .NET-isolerade processfunktioner. Stöd för net7.0 och net48 är för närvarande i förhandsversion.

Anteckning

Azure Functions 4.x kräver Microsoft.NET.Sdk.Functions att tillägget är minst 4.0.0.

Uppdatera 2.x-appar till 3.x i Visual Studio

Du kan öppna en befintlig funktion som är inriktad på 2.x och gå över till 3.x genom att redigera .csproj filen och uppdatera värdena ovan. Visual Studio hanterar körningsversioner automatiskt baserat på projektmetadata. Det är dock möjligt om du aldrig har skapat en 3.x-app tidigare som Visual Studio ännu inte har mallarna och körningsmiljön för 3.x på datorn. Det här problemet kan visa sig med ett fel som "no Functions runtime available that matches the version specified in the project". Om du vill hämta de senaste mallarna och körningen går du igenom upplevelsen för att skapa ett nytt funktionsprojekt. När du kommer till skärmen för att välja version och mall väntar du tills Visual Studio har hämtat de senaste mallarna. När de senaste .NET Core 3-mallarna är tillgängliga och visas kan du köra och felsöka alla projekt som konfigurerats för version 3.x.

Viktigt

Version 3.x-funktioner kan bara utvecklas i Visual Studio om du använder Visual Studio version 16.4 eller senare.

VS Code och Azure Functions Core Tools

Azure Functions Core Tools används för kommandoradsutveckling och även av Azure Functions-tillägget för Visual Studio Code. Om du vill utveckla mot version 3.x installerar du version 3.x av Core Tools. Version 2.x-utveckling kräver version 2.x av Core Tools och så vidare. Mer information finns i Installera Azure Functions Core Tools.

För Visual Studio Code-utveckling kan du också behöva uppdatera användarinställningen azureFunctions.projectRuntime för för att matcha versionen av de installerade verktygen. Den här inställningen uppdaterar även de mallar och språk som används när funktionsappen skapas. Om du vill skapa appar i ~3uppdaterar du användarinställningen azureFunctions.projectRuntime till ~3.

Azure Functions tilläggskörningsinställning

Maven- och Java-appar

Du kan migrera Java-appar från version 2.x till 3.x genom att installera 3.x-versionen av de kärnverktyg som krävs för att köras lokalt. När du har kontrollerat att appen fungerar korrekt lokalt på version 3.x uppdaterar du appens POM.xml fil för att ändra FUNCTIONS_EXTENSION_VERSION inställningen till ~3, som i följande exempel:

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

Bindningar

Från och med version 2.x använder körningen en ny utökningsmodell för bindning som erbjuder följande fördelar:

  • Stöd för bindningstillägg från tredje part.

  • Avkoppling av körning och bindningar. Den här ändringen gör att bindningstillägg kan versionshanteras och släppas oberoende av varandra. Du kan till exempel välja att uppgradera till en version av ett tillägg som förlitar sig på en nyare version av en underliggande SDK.

  • En lättare körningsmiljö där endast de bindningar som används är kända och läses in av körningen.

Förutom HTTP- och timerutlösare måste alla bindningar uttryckligen läggas till i funktionsappprojektet eller registreras i portalen. Mer information finns i Registrera bindningstillägg.

I följande tabell visas vilka bindningar som stöds i varje körningsversion.

Den här tabellen visar bindningar som stöds i huvudversionerna av Azure Functions-körningen:

Typ 1.x 2.x och högre1 Utlösare Indata Resultat
Blob Storage
Azure Cosmos DB
Azure SQL (förhandsversion)
Dapr3
Event Grid
Event Hubs
HTTP-webhooks &
IoT Hub
Kafka2
Mobilappar
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 Från och med version 2.x-körningen måste alla bindningar utom HTTP och Timer registreras. Se Registrera bindningstillägg.

2 Utlösare stöds inte i förbrukningsplanen. Kräver körningsdrivna utlösare.

3 Stöds endast i Kubernetes, IoT Edge och andra lägen med egen värd.

Varaktighet för tidsgräns för funktionsapp

Tidsgränsen för en funktionsapp definieras av functionTimeout egenskapen i projektfilen host.json . I följande tabell visas standardvärdena och maxvärdena (i minuter) för specifika planer:

Planera Standardvärde Maximalt1
Förbrukningsplan 5 10
Premiumplan 302 Obegränsat
Dedikerad plan 302 Obegränsat

1 Oavsett tidsgränsinställningen för funktionsappen är 230 sekunder den maximala tid som en HTTP-utlöst funktion kan ta för att svara på en begäran. Detta beror på den inaktiva standardtidsgränsen för Azure Load Balancer. Överväg att använda Durable Functions asynkront mönster för längre bearbetningstider eller skjuta upp det faktiska arbetet och returnera ett omedelbart svar.
2 Standardtidsgränsen för version 1.x av Functions-körningen är obegränsad.

Nästa steg

Mer information finns i följande resurser: