Übersicht über die Runtimeversionen von Azure Functions

Azure Functions unterstützt derzeit mehrere Versionen des Runtime-Hosts. In der folgenden Tabelle sind die verfügbaren Versionen, deren Supportebene und wann Sie sie benutzen sollten, aufgeführt:

Version Supportebene Beschreibung
4.x Allgemein verfügbar Empfohlene Runtime-Version für Funktionen in allen Sprachen. Verwenden Sie diese Version, um C#-Funktionen auf .NET 6.0, .NET 7.0 und .NET Framework 4.8 auszuführen.
3.x Allgemein verfügbar Unterstützt alle Sprachen. Verwenden Sie diese Version, um C#-Funktionen unter .NET Core 3.1 und .NET 5.0 auszuführen.
2.x Allgemein verfügbar Wird für ältere Versionen von 2.x-Apps unterstützt. Diese Version befindet sich im Wartungsmodus. Verbesserungen werden erst in späteren Versionen bereitgestellt.
1.x Allgemein verfügbar Wird nur für C#-Apps empfohlen, die .NET Framework verwenden müssen und unterstützt nur die Entwicklung im Azure-Portal, Azure Stack Hub-Portal oder lokal auf Windows. Diese Version befindet sich im Wartungsmodus. Verbesserungen werden erst in späteren Versionen bereitgestellt.

Wichtig

Ab dem 3. Dezember 2022 können auf den Versionen 2.x und 3.x der Azure Functions-Runtime ausgeführte Funktions-Apps nicht mehr unterstützt werden. Vorher sollten Sie Ihre Funktions-Apps testen und überprüfen und zu Version 4.x der Functions-Runtime migrieren. Weitere Informationen finden Sie unter Migrieren von 3.x zu 4.x. Nach dem Stichtag können Funktions-Apps erstellt und bereitgestellt werden, und vorhandene Apps werden weiterhin ausgeführt. Ihre Apps sind jedoch erst für neue Features, Sicherheitspatches, Leistungsoptimierungen und Support berechtigt, wenn Sie ein Upgrade auf Version 4.x durchführen.

Das Ende der Unterstützung für diese Runtimeversionen ist auf das Ende der Unterstützung für .NET Core 3.1 zurückzuführen, das diese älteren Runtimeversionen benötigen. Diese Anforderung betrifft alle Azure Functions-Runtimesprachen.
Functions-Version 1.x wird weiterhin für C#-Funktions-Apps unterstützt, die .NET Framework erfordern. Die Vorschauunterstützung ist jetzt in Functions 4.x verfügbar, um C#-Funktionen auf .NET Framework 4.8 auszuführen.

In diesem Artikel werden einige Unterschiede zwischen diesen Versionen, das Erstellen der einzelnen Versionen und das Ändern von Versionen, in denen Ihre Funktionen laufen, erläutert.

Unterstützungsebenen

Es gibt zwei Unterstützungsebenen:

  • Allgemein verfügbar (generally available, GA) : Vollständige Unterstützung und Freigabe für die Verwendung in Produktionsumgebungen.
  • Vorschau: Noch nicht unterstützt, die Erreichung der allgemeinen Verfügbarkeit wird aber für die Zukunft erwartet.

Languages

Alle Funktionen in einer Funktions-App müssen die gleiche Sprache verwenden. Sie haben beim Erstellen der App die Sprache der Funktionen in Ihrer Funktions-App ausgewählt. Die Sprache Ihrer Funktions-App wird in der Einstellung FUNCTIONS_WORKER_RUNTIME beibehalten und sollte nicht geändert werden, wenn Funktionen vorhanden sind.

Die folgende Tabelle zeigt, welche Programmiersprachen derzeit in den einzelnen Runtimeversionen unterstützt werden.

Sprache 1.x 2.x 3.x 4.x
C# Allgemeine Verfügbarkeit (.NET Framework 4.8) Allgemeine Verfügbarkeit (.NET Core 2.11) Allgemeine Verfügbarkeit (.NET Core 3.1)
Allgemeine Verfügbarkeit (.NET 5.0)
Allgemeine Verfügbarkeit (.NET 6.0)
Vorschau (.NET 7)
Vorschau (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10 und 8) GA (Node.js 14, 12 und 10) GA (Node.js 14)
GA (Node.js 16)
Vorschau (Node.js 18)
F# Allgemeine Verfügbarkeit (.NET Framework 4.8) Allgemeine Verfügbarkeit (.NET Core 2.11) Allgemeine Verfügbarkeit (.NET Core 3.1) Allgemeine Verfügbarkeit (.NET 6.0)
Java Allgemeine Verfügbarkeit (Java 8) GA (Java 11 und 8) GA (Java 11 und 8)
Vorschau (Java 17)
PowerShell Allgemeine Verfügbarkeit (PowerShell Core 6) GA (PowerShell 7.0 und Core 6) Allgemeine Verfügbarkeit (PowerShell 7.2)
Python GA (Python 3.7 und 3.6) GA (Python 3.9, 3.8, 3.7 und 3.6) GA (Python 3.9, 3.8, 3.7)
TypeScript2 Allgemein verfügbar Allgemein verfügbar Allgemein verfügbar

1 Apps mit .NET-Klassenbibliotheken für Runtimeversion 2.x werden im .NET Core 2.x-Kompatibilitätsmodus unter .NET Core 3.1 ausgeführt. Weitere Informationen finden Sie unter Überlegungen zu Functions v2.x.
2 Unterstützt durch Transpilierung in JavaScript

Weitere Informationen zu unterstützten Sprachversionen finden Sie im sprachspezifischen Artikel im Entwicklerhandbuch.
Informationen zu geplanten Änderungen an der Sprachunterstützung finden Sie unter Azure-Roadmap.

Ausführen auf einer spezifischen Version

Im Azure-Portal und über die Azure CLI erstellte Funktions-Apps sind standardmäßig auf Version 4.x festgelegt. Diese Version kann bei Bedarf geändert werden. Für die Runtimeversion kann nur ein Downgrade in 1.x ausgeführt werden, wenn Sie Ihre Funktions-App erstellt, aber noch keine Funktionen hinzugefügt haben. Der Wechsel zu einer höheren Version ist auch bei Apps möglich, die bereits über Funktionen verfügen. Wenn Ihre App bereits über Funktionen verfügt, machen Sie sich mit allen Breaking Changes zwischen Versionen vertraut, bevor Sie zu einer späteren Runtimeversion wechseln. In den folgenden Abschnitten werden Breaking Changes zwischen Versionen ausführlich beschrieben, einschließlich sprachspezifischer Breaking Changes.

Wenn Ihre Programmiersprache nicht angezeigt wird, wählen Sie sie oben auf der Seite aus.

Bevor Sie eine Änderung an der Hauptversion der Runtime vornehmen, sollten Sie zunächst Ihren vorhandenen Code mit der neuen Version der Runtime testen. Sie können überprüfen, ob Ihre App nach dem Upgrade ordnungsgemäß ausgeführt wird, indem Sie eine andere Funktions-App bereitstellen, die auf der neuesten Hauptversion ausgeführt wird. Sie können Ihren Code auch lokal überprüfen, indem Sie die laufzeitspezifische Version der Azure Functions Core Tools verwenden, die die Functions-Runtime enthält.

Downgrades auf v2.x werden nicht unterstützt. Wenn möglich, sollten Sie Ihre Apps immer mit der neuesten unterstützten Version der Functions-Laufzeit ausführen.

Ändern der Version von Apps in Azure

Welche Version der Functions-Runtime von veröffentlichten Apps in Azure verwendet wird, wird durch die FUNCTIONS_EXTENSION_VERSION-Anwendungseinstellung bestimmt. Für die Hauptversion der Runtime werden folgende Werte unterstützt:

Wert Runtimeziel
~4 4.x
~3 3.x
~2 2.x
~1 1.x

Wichtig

Ändern Sie diese App-Einstellung mit Bedacht, da hierdurch unter Umständen weitere Änderungen an App-Einstellungen und Ihrem Funktionscode nötig werden. Es empfiehlt sich, diese Einstellung stattdessen im Azure-Portal auf der Registerkarte Einstellungen der Funktionsruntime der Konfiguration der Funktions-App zu ändern, wenn Sie ein Upgrade der Hauptversion vornehmen möchten.

Weitere Informationen finden Sie unter How to target Azure Functions runtime versions (Einstellung auf bestimmte Laufzeitversionen von Azure Functions).

Anheften an eine bestimmte Nebenversion

Um mögliche Probleme Ihrer Funktions-App beim Ausführen der neuesten Hauptversion zu beheben, müssen Sie Ihre App vorübergehend an eine bestimmte Nebenversion anheften. Anheften gibt Ihnen Zeit, Ihre App mit der neuesten Hauptversion ordnungsgemäß auszuführen. Die Art und Weise, wie Sie die App an eine Nebenversion anheften, unterscheidet sich zwischen Windows und Linux. Weitere Informationen finden Sie unter How to target Azure Functions runtime versions (Einstellung auf bestimmte Laufzeitversionen von Azure Functions).

Ältere Nebenversionen werden regelmäßig aus Functions entfernt. Aktuelle Informationen zu Azure Functions Releases (einschließlich der Entfernung bestimmter älterer Nebenversionen) finden Sie unter Azure App Service-Ankündigungen.

Anheften an Version ~2.0

.NET-Funktions-Apps, die mit Version 2.x (~2) ausgeführt werden, werden automatisch auf .NET Core 3.1 aktualisiert, eine langfristige Supportversion von .NET Core 3. Wenn Sie Ihre .NET-Funktionen mit .NET Core 3.1 ausführen, können Sie die neuesten Sicherheitsupdates und Produktverbesserungen nutzen.

Jede Funktions-App, die an ~2.0 angeheftet wird, kann weiterhin unter .NET Core 2.2 ausgeführt werden. Diese Version erhält keine Sicherheitsupdates und andere Updates mehr. Weitere Informationen finden Sie unter Überlegungen zu Functions v2.x.

Mindesterweiterungsversionen

Es gibt eigentlich keinen Zusammenhang zwischen Bindungserweiterungsversionen und der Functions-Runtimeversion. Ab Version 4.x erzwingt die Functions-Runtime allerdings eine Mindestversion für alle Trigger- und Bindungserweiterungen.

Wenn Sie eine Warnung mit dem Hinweis erhalten, dass ein Paket eine erforderliche Mindestversion nicht erfüllt, sollten Sie dieses NuGet-Paket wie gewohnt auf die Mindestversion aktualisieren. Die Mindestversionsanforderungen für Erweiterungen in Functions 4.x finden Sie in dieser verknüpften Konfigurationsdatei.

Aktualisieren Sie für C#-Skripts den Erweiterungsbündelverweis in „host.json“ wie folgt:

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

Es gibt eigentlich keinen Zusammenhang zwischen Erweiterungsbündelversionen und der Functions-Runtimeversion. Ab Version 4.x erzwingt die Functions-Runtime allerdings eine Mindestversion für Erweiterungsbündel.

Wenn Sie eine Warnung mit dem Hinweis erhalten, dass Ihre Erweiterungsbündelversion eine erforderliche Mindestversion nicht erfüllt, aktualisieren Sie Ihren vorhandenen Erweiterungsbündelverweis in „host.json“ wie folgt:

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

Weitere Informationen zu Erweiterungsbündeln finden Sie unter Erweiterungsbündel.

Migrieren von 3.x zu 4.x

Die Azure Functions-Version 4.x bietet eine hohe Abwärtskompatibilität mit der Version 3.x. Bei den meisten Apps sollte ein Upgrade auf Version 4.x ohne erhebliche Codeänderungen problemlos möglich sein. Ein Upgrade wird initiiert, wenn Sie die FUNCTIONS_EXTENSION_VERSION-App-Einstellung auf einen Wert von ~4 setzen. Für Funktions-Apps, die unter Windows ausgeführt werden, müssen Sie auch die netFrameworkVersion-Standorteinstellung auf .NET 6 festlegen.

Bevor Sie Ihre App auf Version 4.x der Functions-Runtime aktualisieren, sollten Sie die folgenden Aufgaben ausführen:

Ausführen des Vorupgrade-Validierungssteuerelements

Azure Functions bietet ein Vorupgrade-Validierungssteuerelement, um potenzielle Probleme beim Migrieren der Funktions-App auf 4.x zu erkennen. So führen Sie das Vorupgrade-Validierungssteuerelement aus:

  1. Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.

  2. Öffnen Sie die Seite Diagnose und Problembehandlung.

  3. Beginnen Sie in der Funktions-App-Diagnose mit der Eingabe von Functions 4.x Pre-Upgrade Validator, und wählen Sie es dann aus der Liste aus.

  4. Überprüfen Sie nach Abschluss der Überprüfung die Empfehlungen, und behandeln Sie alle Probleme in Ihrer App. Wenn Sie Änderungen an Ihrer App vornehmen müssen, überprüfen Sie die Änderungen anhand der Version 4.x der Functions-Runtime, entweder lokal mithilfe der Azure Functions Core Tools v4 oder mithilfe eines Stagingslots.

Migrieren ohne Slots

Die einfachste Möglichkeit zum Upgrade auf v4.x besteht darin, die FUNCTIONS_EXTENSION_VERSION-Anwendungseinstellung in Ihrer Funktions-App in Azure auf ~4 festzulegen. Wenn Ihre Funktions-App unter Windows ausgeführt wird, müssen Sie auch die netFrameworkVersion-Standorteinstellung in Azure aktualisieren. Sie müssen ein anderes Verfahren an einem Standort mit Slots ausführen.

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

Bei Ausführung unter Windows müssen Sie auch .NET 6.0 aktivieren, das für Version 4.x der Runtime erforderlich ist.

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

Ersetzen Sie in diesen Beispielen <APP_NAME> durch den Namen Ihrer Funktions-App und <RESOURCE_GROUP_NAME> durch den Namen der Ressourcengruppe.

Migrieren mit Slots

Die Verwendung von Bereitstellungsslots ist eine gute Möglichkeit, Ihre Funktions-App von einer früheren Version zur v4.x-Runtime zu migrieren. Mithilfe eines Stagingslos können Sie Ihre App auf der neuen Runtimeversion im Stagingslot ausführen und nach der Überprüfung zur Produktion wechseln. Slots bieten auch eine Möglichkeit, Downtime während des Upgrades zu minimieren. Wenn Sie Downtime minimieren müssen, führen Sie die Schritte unter Upgrade mit minimaler Downtime aus.

Nachdem Sie Ihre App im aktualisierten Slot überprüft haben, können Sie die App und neue Versionseinstellungen in der Produktion übernehmen. Dieser Wechsel erfordert die Einstellung WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 im Produktionsslot. Wie Sie diese Einstellung hinzufügen, wirkt sich auf die Länge der für das Upgrade erforderlichen Downtime aus.

Standardupgrade

Wenn Ihre Funktions-App mit Slotunterstützung die Downtime eines vollständigen Neustarts verarbeiten kann, können Sie die WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS-Einstellung direkt im Produktionsslot aktualisieren. Da das Ändern dieser Einstellung direkt im Produktionsslot einen Neustart verursacht, der sich auf die Verfügbarkeit auswirkt, sollten Sie diese Änderung zu einem Zeitpunkt mit reduziertem Datenverkehr in Betracht ziehen. Anschließend können Sie die aktualisierte Version aus dem Stagingslot übernehmen.

Das Update-AzFunctionAppSetting-PowerShell-Cmdlet unterstützt derzeit keine Slots. Sie müssen Azure CLI oder das Azure-Portal verwenden.

  1. Verwenden Sie den folgenden Befehl, um im Produktionslot WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 festzulegen:

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

    Dieser Befehl bewirkt, dass die im Produktionslot ausgeführte App neu gestartet wird.

  2. Verwenden Sie den folgenden Befehl, um auch im Stagingslot WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS festzulegen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  3. Verwenden Sie den folgenden Befehl, um FUNCTIONS_EXTENSION_VERSION zu ändern und den Stagingslot auf die neue Runtimeversion zu aktualisieren:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  4. (Nur Windows) Verwenden Sie für Funktions-Apps, die unter Windows ausgeführt werden, den folgenden Befehl, damit die Runtime auf .NET 6 ausgeführt werden kann:

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

    Version 4.x der Functions-Runtime erfordert .NET 6 bei der Ausführung unter Windows.

  5. Wenn für Ihr Codeprojekt Updates erforderlich sind, die auf Version 4.x ausgeführt werden sollen, stellen Sie diese Updates jetzt für den Stagingslot bereit.

  6. Vergewissern Sie sich vor dem Austausch, dass Ihre Funktions-App ordnungsgemäß in der aktualisierten Stagingumgebung ausgeführt wird.

  7. Verwenden Sie den folgenden Befehl, um den aktualisierten Stagingslot in die Produktion zu übernehmen:

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

Upgrade mit minimaler Downtime

Um die Downtime in Ihrer Produktions-App zu minimieren, können Sie die WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS-Einstellung vom Stagingslot in die Produktion übernehmen. Danach können Sie von einem vordefinierten Stagingslot die aktualisierte Version übernehmen.

  1. Verwenden Sie den folgenden Befehl, um WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 im Stagingslot festzulegen:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  2. Verwenden Sie die folgenden Befehle, um den Slot mit der neuen Einstellung in die Produktion zu übernehmen und gleichzeitig die Versionseinstellung im Stagingslot wiederherzustellen.

    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>
    

    Während der Zeit zwischen dem Austausch und der Runtimeversion, die beim Staging wiederhergestellt wird, werden möglicherweise Fehler vom Stagingslot angezeigt. Dies kann passieren, weil die FUNCTIONS_EXTENSION_VERSION-Einstellung im Staging entfernt wird, wenn WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 während eines Austausches nur im Staging vorhanden ist. Ohne die Versionseinstellung befindet sich Ihr Slot in einem schlechten Zustand. Wenn Sie die Version im Stagingslot direkt nach dem Austausch aktualisieren, sollte der Slot wieder in einen guten Zustand versetzt werden, damit Sie bei Bedarf ein Rollback Ihrer Änderungen durchführen können. Ein Rollback des Austausches erfordert jedoch auch, dass Sie WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 direkt aus der Produktion entfernen, bevor der Austausch zurückgesetzt wird, um die gleichen Fehler, die im Staging auftreten, in der Produktion zu verhindern. Diese Änderung in der Produktionseinstellung würde dann einen Neustart verursachen.

  3. Verwenden Sie den folgenden Befehl, um WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 wieder im Stagingslot festzulegen:

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

    An diesem Punkt ist für beide Slots WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 festgelegt.

  4. Verwenden Sie den folgenden Befehl, um FUNCTIONS_EXTENSION_VERSION zu ändern und den Stagingslot auf die neue Runtimeversion zu aktualisieren:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  5. (Nur Windows) Verwenden Sie für Funktions-Apps, die unter Windows ausgeführt werden, den folgenden Befehl, damit die Runtime auf .NET 6 ausgeführt werden kann:

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

    Version 4.x der Functions-Runtime erfordert .NET 6 bei der Ausführung unter Windows.

  6. Wenn für Ihr Codeprojekt Updates erforderlich sind, die auf Version 4.x ausgeführt werden sollen, stellen Sie diese Updates jetzt für den Stagingslot bereit.

  7. Vergewissern Sie sich vor dem Austausch, dass Ihre Funktions-App ordnungsgemäß in der aktualisierten Stagingumgebung ausgeführt wird.

  8. Verwenden Sie den folgenden Befehl, um den aktualisierten und vordefinierten Stagingslot in die Produktion zu übernehmen:

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

Upgrade Ihres lokalen Projekts

Upgradeanweisungen können sprachabhängig sein. Wenn Ihre Sprache nicht angezeigt wird, wählen Sie sie oben im Artikel aus.

So aktualisieren Sie ein C#-Klassenbibliotheksprojekt auf .NET 6 und Azure Functions 4.x:

  1. Aktualisieren Sie Ihre lokale Installation der Azure Functions Core Tools auf Version 4.

  2. Aktualisieren Sie TargetFramework und AzureFunctionsVersion wie folgt:

    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    
  3. Aktualisieren Sie die NuGet-Pakete, auf die Ihre App verweist, auf die neuesten Versionen. Weitere Informationen finden Sie unter Breaking Changes.
    Bestimmte Pakete hängen davon ab, ob Ihre Funktionen in-process oder out-of-process ausgeführt werden.

So aktualisieren Sie Ihr Projekt auf Azure Functions 4.x:

  1. Aktualisieren Sie Ihre lokale Installation der Azure Functions Core Tools auf Version 4.x.

  2. Aktualisieren Sie das Azure Functions-Erweiterungenbundle Ihrer App auf 2.x oder höher. Weitere Informationen finden Sie unter Breaking Changes.

  1. Wenn Sie Version 10 oder 12 von Node.js verwenden, wechseln Sie zu einer der unterstützten Versionen.
  1. Wenn Sie PowerShell Core 6 verwenden, wechseln Sie zu einer der unterstützten Versionen.
  1. Wenn Sie Python 3.6 verwenden, wechseln Sie zu einer der unterstützten Versionen.

Wichtige Unterschiede zwischen 3.x und 4.x

Nachfolgend finden Sie wichtige Breaking Changes, die vor dem Upgrade einer 3.x-App auf 4.x beachtet werden müssen, einschließlich sprachspezifischer Breaking Changes. Eine vollständige Liste finden Sie unter Azure Functions GitHub mit der Bezeichnung Breaking Change: Approved. Während des Vorschauzeitraums werden weitere Änderungen erwartet. Abonnieren Sie App Service Ankündigungen für Updates.

Wenn Ihre Programmiersprache nicht angezeigt wird, wählen Sie sie oben auf der Seite aus.

Typ

  • Azure Functions Proxys ist ein Legacyfeature für Versionen 1.x bis 3.x der Azure Functions Laufzeit. Die Unterstützung für Funktionen-Proxys wird in Version 4.x zurückgegeben, sodass Sie Ihre Funktions-Apps erfolgreich auf die neueste Laufzeitversion aktualisieren können. So schnell wie möglich sollten Sie stattdessen zur Integration Ihrer Funktions-Apps in Azure API Management wechseln. API Management können Sie einen umfassenderen Satz von Features nutzen, um Ihre funktionenbasierten APIs zu definieren, zu sichern, zu verwalten und zu monetarisieren. Weitere Informationen finden Sie unter ExpressRoute CrossConnection API Entwicklung und Integration.‘ Informationen zur ausstehenden Rückgabe von Proxys in Version 4.x erhalten Sie auf der Seite App Service Ankündigungen überwachen.

  • Sich bei Azure Storage mithilfe von AzureWebJobsDashboard anzumelden, wird in 4.x nicht mehr unterstützt. Es empfiehlt sich, stattdessen Application Insights zu verwenden. (#1923)

  • Azure Functions 4.x erzwingt nun Mindestversionsanforderungen für Erweiterungen. Führen Sie ein Upgrade auf die neueste Version der betroffenen Erweiterungen durch. Für non-.NET Sprachen führen Sie ein Upgrade auf Version 2.x oder höher des Erweiterungspakets durch. (#1987)

  • Standardmäßige und maximale Timeouts werden nun in 4.x für Funktions-Apps erzwungen, die unter Linux im Rahmen eines Verbrauchsplans ausgeführt werden. (#1915)

  • Azure Functions 4.x verwendet Azure.Identity und Azure.Security.KeyVault.Secrets für den Key Vault-Anbieter. Die Verwendung von „Microsoft.Azure.KeyVault“ ist veraltet. Weitere Informationen zum Konfigurieren der Einstellungen für Funktions-Apps finden Sie in Geheimnis-Repositorys unter der Schlüsseltresoroption. (#2048)

  • Funktions-Apps mit gemeinsam genutzten Speicherkonten können nicht mehr gestartet werden, wenn ihre Host-IDs identisch sind. Weitere Informationen finden Sie unter Überlegungen zur Host-ID. (#2049)

  • Azure Functions 4.x unterstützt .NET 6 In-Process und isolierte Apps.

  • InvalidHostServicesException ist jetzt ein schwerwiegender Fehler. (#2045)

  • EnableEnhancedScopes ist standardmäßig aktiviert. (#1954)

  • Entfernt HttpClient als registrierten Dienst. (#1911)

  • Verwenden eines Klassenladers in Java 11. (#1997)

  • Beendet das Laden von Worker-JAR-Dateien in Java 8. (#1991)

  • Die Node.js-Versionen 10 und 12 werden von Azure Functions 4.x nicht unterstützt. (#1999)

  • Die Ausgabeserialisierung in Node.js-Apps wurde aktualisiert, um frühere Inkonsistenzen zu beheben. (#2007)

  • PowerShell 6 wird von Azure Functions 4.x nicht unterstützt. (#1999)

  • Standardthreadanzahl wurde aktualisiert. Funktionen, die nicht threadsicher sind oder eine hohe Arbeitsspeicherauslastung mit sich bringen, können betroffen sein. (#1962)

  • Python 3.6 wird von Azure Functions 4.x nicht unterstützt. (#1999)

  • Shared Memory-Übertragung ist standardmäßig aktiviert. (#1973)

  • Standardthreadanzahl wurde aktualisiert. Funktionen, die nicht threadsicher sind oder eine hohe Arbeitsspeicherauslastung mit sich bringen, können betroffen sein. (#1962)

Migrieren von 2.x zu 3.x

Die Azure Functions-Version 3.x bietet eine hohe Abwärtskompatibilität mit der Version 2.x. Bei vielen Apps sollte problemlos ein Upgrade auf die Version 3.x möglich sein, ohne Codeänderungen vornehmen zu müssen. Die Migration zur Version 3.x wird zwar empfohlen, trotzdem sollten ausführliche Tests durchgeführt werden, bevor die Hauptversion in Produktions-Apps geändert wird.

Breaking Changes zwischen 2.x und 3.x

In diesem Abschnitt werden die Änderungen erläutert, die vor einem App-Upgrade von 2.x auf 3.x beachtet werden müssen. Wenn Ihre Programmiersprache nicht angezeigt wird, wählen Sie sie oben auf der Seite aus.

Der Hauptunterschied zwischen den Versionen bei der Ausführung von Funktionen der .NET-Klassenbibliothek ist die .NET Core-Laufzeit. Functions Version 2.x ist für die Ausführung unter .NET Core 2.2 vorgesehen, Version 3.x ist für die Ausführung mit .NET Core 3.1 konzipiert.

Hinweis

Aufgrund von Supportproblemen mit .NET Core 2.2 werden Funktions-Apps, die an Version 2 (~2) angeheftet sind, im Wesentlichen mit .NET Core 3.1 ausgeführt. Weitere Informationen finden Sie unter Functions v2.x-Kompatibilitätsmodus.

  • Über 1.x context.done oder Rückgabewerte zugewiesene Ausgabebindungen weisen nun das gleiche Verhalten auf wie die Einstellung in 2.x context.bindings oder höher.

  • Das Zeitgebertrigger-Objekt wird im camelCase-Format angegeben (nicht im PascalCase-Format).

  • Funktionen, die von einem Event Hub mit binärem Datentyp (dataType) ausgelöst werden, erhalten ein Array vom Typ binary (anstelle von string).

  • Auf die Nutzlast von HTTP-Anforderungen kann nicht mehr über context.bindingData.req zugegriffen werden. Der Zugriff darauf ist aber weiterhin als Eingabeparameter (context.req) und in context.bindings möglich.

  • Node.js 8 wird nicht mehr unterstützt und in Funktionen der Version 3.x nicht ausgeführt.

Migrieren von 1.x zu neueren Versionen

Eine vorhandene App, die für die Runtimeversion 1.x geschrieben wurde, kann zu einer neueren Version migriert werden. Die meisten erforderlichen Änderungen hängen mit der Sprachruntime zusammen – also beispielsweise C#-API-Änderungen zwischen .NET Framework 4.8 und .NET Core. Sie müssen auch sicherstellen, dass Ihr Code und Ihre Bibliotheken mit den ausgewählten Sprachruntimes kompatibel sind. Beachten Sie nicht zuletzt auch die unten genannten Änderungen an Triggern, Bindungen und Funktionen. Um ein optimales Migrationsergebnis zu erzielen, sollten Sie eine neue Funktions-App in einer neuen Version erstellen und Ihren vorhandenen Funktionscode der Version 1.x zur neuen App portieren.

Es besteht zwar die Möglichkeit eines direkten Upgrades durch manuelles Aktualisieren der App-Konfiguration, die Umstellung von 1.x auf eine höhere Version beinhaltet jedoch einige Breaking Changes. In C# ändert sich beispielsweise das Debuggingobjekt von TraceWriter in ILogger. Durch die Erstellung eines neuen Projekts mit der Version 3.x stehen die aktualisierten Funktionen auf der Grundlage der neuesten Vorlagen der Version 3.x zur Verfügung.

Änderungen bei Triggern und Bindungen nach der Version 1.x

Ab der Version 2.x müssen die Erweiterungen für bestimmte Trigger und Bindungen installiert werden, die von den Funktionen in Ihrer App verwendet werden. Die einzigen Ausnahmen sind HTTP- und Timertrigger, für die keine Erweiterung erforderlich ist. Weitere Informationen finden Sie unter Registrieren und Installieren von Bindungserweiterungen.

Zwischen den Versionen gibt es auch einige Änderungen an der Datei function.json sowie an Attributen der Funktion. Beispielsweise lautet die Event Hubs-Eigenschaft path jetzt eventHubName. Links zur Dokumentation für die einzelnen Bindungen finden Sie in der Tabelle der vorhandenen Bindungen.

Änderungen bei Features und Funktionen nach der Version 1.x

Einige Features wurden nach der Version 1.x entfernt, aktualisiert oder ersetzt. In diesem Abschnitt werden die Änderungen nach der Version 1.x erläutert.

In Version 2.x wurden die folgenden Änderungen vorgenommen:

  • Schlüssel für aufrufende HTTP-Endpunkte werden immer verschlüsselt in Azure Blob Storage gespeichert. In Version 1.x wurden Schlüssel standardmäßig in Azure Files gespeichert. Bei einem App-Upgrade von Version 1.x auf Version 2.x werden in Azure Files vorhandene Geheimnisse zurückgesetzt.

  • Version 2.x der Runtime umfasst keine integrierte Unterstützung für Webhookanbieter. Diese Änderung wurde vorgenommen, um die Leistung zu verbessern. Sie können weiterhin HTTP-Trigger als Endpunkte für Webhooks verwenden.

  • Die Hostkonfigurationsdatei (host.json) muss leer sein oder die Zeichenfolge "version": "2.0" enthalten.

  • Zur Verbesserung der Überwachung wurde das WebJobs-Dashboard im Portal, das die Einstellung AzureWebJobsDashboard verwendete, durch Azure Application Insights ersetzt – hierbei wird die Einstellung APPINSIGHTS_INSTRUMENTATIONKEY verwendet. Weitere Informationen finden Sie unter Überwachen von Azure Functions.

  • Alle Funktionen in einer Funktions-App müssen die gleiche Sprache verwenden. Wenn Sie eine Funktions-App erstellen, müssen Sie einen Runtimestapel für die App auswählen. Der Runtimestapel wird durch den FUNCTIONS_WORKER_RUNTIME-Wert in den Anwendungseinstellungen angegeben. Diese Anforderung wurde hinzugefügt, um den Speicherbedarf und die Startzeit zu verbessern. Bei der lokalen Entwicklung müssen Sie diese Einstellung auch in die Datei „local.settings.json“ einschließen.

  • Das Standardzeitlimit für Funktionen in einem App Service-Plan wurde zu 30 Minuten geändert. Sie können das Zeitlimit mit der functionTimeout-Einstellung in der host.json-Datei manuell wieder zu „unbegrenzt“ ändern.

  • HTTP-Parallelitätsdrosselungen sind standardmäßig für Verbrauchsplanfunktionen implementiert. Der Standardwert beträgt 100 gleichzeitige Anforderungen pro Instanz. Sie können dieses Verhalten in der maxConcurrentRequests-Einstellung in der host.json-Datei ändern.

  • Aufgrund der Einschränkungen von .NET Core wurde die Unterstützung von F#-Skriptfunktionen (Dateien vom Typ .fsx) entfernt. Kompilierte F#-Funktionen (FS) werden weiterhin unterstützt.

  • Das URL-Format von Event Grid-Triggerwebhooks wurde geändert und hat nun das folgende Muster: https://{app}/runtime/webhooks/{triggerName}.

Lokal entwickelte Anwendungsversionen

Sie können folgende Aktualisierungen für Funktions-Apps vornehmen, um die Zielversionen lokal zu ändern.

Visual Studio-Runtimeversionen

In Visual Studio wählen Sie die Runtimeversion beim Erstellen eines Projekts aus. Azure Functions-Tools für Visual Studio unterstützen die drei Hauptversionen der Runtime. Beim Debuggen und Veröffentlichen wird die richtige Version verwendet, basierend auf den Projekteinstellungen. Die Versionseinstellungen sind in der .csproj-Datei in den folgenden Einstellungen definiert:

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

Sie können auch net6.0, net7.0 oder net48 als Zielframework auswählen, wenn Sie isolierte .NET-Prozessfunktionen verwenden. Die Unterstützung von net7.0 und net48 befindet sich derzeit in der Vorschauphase.

Hinweis

Für Azure Functions 4.x und .NET muss die Microsoft.NET.Sdk.Functions-Erweiterung mindestens die Version 4.0.0haben.

Aktualisieren von Apps der Version 2.x auf die Version 3.x in Visual Studio

Sie können eine bereits vorhandene, für die Version 2.x konzipierte Funktion öffnen und zu 3.x migrieren, indem Sie die Datei .csproj bearbeiten und die obigen Werte aktualisieren. Visual Studio verwaltet Runtimeversionen automatisch auf der Grundlage der Projektmetadaten. Sollten Sie allerdings bislang noch keine App der Version 3.x erstellt haben, kann es sein, dass Visual Studio auf Ihrem Computer noch nicht über die Vorlagen und die Runtime für die Version 3.x verfügt. In diesem Fall tritt ggf. ein Fehler wie der folgende auf: „Es ist keine Functions-Runtime verfügbar, die der im Projekt angegebenen Version entspricht.“ Führen Sie die Schritte zum Erstellen eines neuen Funktionsprojekts aus, um die neuesten Vorlagen und die Runtime abzurufen. Wenn Sie zum Auswahlbildschirm für die Version und die Vorlage gelangen, warten Sie, bis Visual Studio die neuesten Vorlagen abgerufen hat. Wenn die neuesten .NET Core 3-Vorlagen verfügbar sind und angezeigt werden, können Sie jedes beliebige Projekt ausführen und debuggen, das für Version 3.x konfiguriert wurde.

Wichtig

Funktionen der Version 3.x können nur in Visual Studio entwickelt werden, wenn Sie mindestens die Visual Studio Version 16.4 verwenden.

Visual Studio Code und Azure Functions Core Tools

Azure Functions Core Tools werden für die Entwicklung über die Befehlszeile und auch von der Azure Functions-Erweiterung für Visual Studio Code verwendet. Wenn Sie für die Version 3.x entwickeln möchten, müssen Sie die Core Tools-Version 3.x installieren. Bei der Entwicklung für die Version 2.x benötigen Sie die Core Tools-Version 2.x. Und so weiter. Weitere Informationen finden Sie unter Installieren der Azure Functions Core Tools.

Für die Visual Studio Code-Entwicklung müssen Sie möglicherweise auch die Benutzereinstellung für die azureFunctions.projectRuntime entsprechend der installierten Version der Tools aktualisieren. Diese Einstellung aktualisiert auch die Vorlagen und Sprachen, die während der Erstellung von Funktions-Apps verwendet werden. Wenn Sie Apps in ~3 erstellen möchten, müssen Sie die Benutzereinstellung azureFunctions.projectRuntime auf ~3 aktualisieren.

Runtimeeinstellung der Azure Functions-Erweiterung

Maven- und Java-Apps

Sie können Java-Apps der Version 2.x zur Version 3.x migrieren, indem Sie die Version 3.x von Core Tools installieren, die für die lokale Ausführung benötigt wird. Nachdem Sie sich vergewissert haben, dass Ihre lokal ausgeführte App unter der Version 3.x ordnungsgemäß funktioniert, können Sie die Datei POM.xml der App aktualisieren, um die Einstellung FUNCTIONS_EXTENSION_VERSION in ~3 zu ändern, wie im folgenden Beispiel zu sehen:

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

Bindungen

Ab Version 2.x verwendet die Runtime ein neues Modell für die Erweiterbarkeit von Bindungen, das folgende Vorteile bietet:

  • Unterstützung für Bindungserweiterungen von Drittanbietern.

  • Entkoppeln von Runtime und Bindungen. Mit dieser Änderung können Bindungserweiterungen versioniert und unabhängig freigegeben werden. Sie können z.B. ein Upgrade auf eine Version einer Erweiterung durchführen, das auf einer neueren Version des zugrunde liegenden SDKs basiert.

  • Eine schlankere Ausführungsumgebung, in der nur die tatsächlich verwendeten Bindungen bekannt sind und von der Runtime geladen werden.

Mit Ausnahme von HTTP- und Timertriggern müssen alle Bindungen explizit zum Funktions-App-Projekt hinzugefügt oder im Portal registriert werden. Weitere Informationen finden Sie unter Registrieren von Bindungserweiterungen.

Die folgende Tabelle zeigt, welche Bindungen in den einzelnen Runtimeversionen unterstützt werden.

Die folgende Tabelle zeigt die Bindungen, die in den Hauptversionen der Azure Functions-Runtime unterstützt werden:

type 1.x 2.x und höher1 Trigger Eingabe Output
Blob Storage
Azure Cosmos DB
Azure SQL (Vorschau)
Dapr3
Event Grid
Event Hubs
HTTP und Webhooks
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Tabellenspeicherung
Zeitgeber
Twilio

1 Ab Version 2.x der Runtime müssen alle Bindungen mit Ausnahme von HTTP und Timer registriert werden. Siehe Registrieren von Bindungserweiterungen.

2 Trigger werden im Verbrauchstarif nicht unterstützt. Erfordert runtimegesteuerte Trigger.

3 Wird nur in Kubernetes, IoT Edge und anderen selbstgehosteten Modi unterstützt.

Funktions-App-Timeoutdauer

Die Timeoutdauer einer Funktions-App wird durch die functionTimeout-Eigenschaft in der functionTimeout-Projektdatei definiert. Die folgende Tabelle zeigt die Standard- und Höchstwerte (in Minuten) für bestimmte Pläne:

Plan Standard Maximum1
Verbrauchsplan 5 10
Premium-Plan 302 Unbegrenzt
Dedizierter Plan 302 Unbegrenzt

1 Unabhängig von der Timeouteinstellung der Funktions-App stellen 230 Sekunden die längste Zeit dar, die einer über HTTP ausgelösten Funktion bis zur Reaktion auf eine Anfrage bleibt. Dies hat seinen Grund im Standard-Leerlauftimeout von Azure Load Balancer. Erwägen Sie für längere Verarbeitungszeiten die Verwendung des asynchronen Durable Functions-Musters oder stellen Sie die eigentliche Arbeit zurück, und geben Sie unmittelbar eine Antwort zurück.
2 Das Standardtimeout für Version 1.x der Functions-Runtime ist unbegrenzt.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen: