Übersicht über die Runtimeversionen von Azure Functions

Azure Functions unterstützt derzeit zwei Versionen des Laufzeithosts. In der folgenden Tabelle sind die derzeit unterstützten Laufzeitversionen, deren Supportebene und wann Sie sie benutzen sollten, aufgeführt:

In diesem Artikel werden einige Unterschiede zwischen unterstützten Versionen, der Erstellung der einzelnen Versionen und dem Ändern von Versionen, in denen Ihre Funktionen ausgeführt werden, 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 wählen die Sprache der Funktionen in Ihrer Funktions-App aus, wenn Sie diese erstellen. Die Sprache Ihrer Funktions-App wird in der Einstellung FUNCTIONS_WORKER_RUNTIME beibehalten und sollte nicht geändert werden, wenn Funktionen vorhanden sind.

Informationen zu geplanten Änderungen an der Sprachunterstützung finden Sie unter Azure-Roadmap.

Informationen zu den Sprachversionen der zuvor unterstützten Versionen der Functions-Laufzeit finden Sie unter Eingestellte Laufzeitversionen.

Ausführen auf einer spezifischen Version

Welche Version der Functions-Runtime von veröffentlichten Apps in Azure verwendet wird, wird durch die FUNCTIONS_EXTENSION_VERSION-Anwendungseinstellung bestimmt. In einigen Fällen und für bestimmte Sprachen gelten möglicherweise andere Einstellungen.

Im Azure-Portal, in der Azure CLI oder mit Visual Studio-Tools 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 Hauptversion ist auch bei Apps möglich, die bereits über Funktionen verfügen.

Migrieren vorhandener Funktions-Apps

Wenn Ihre App über vorhandene Funktionen verfügt, müssen Sie Vorkehrungen treffen, bevor Sie zu einer höheren Runtime-Hauptversion wechseln. In den folgenden Artikeln werden Breaking Changes zwischen Hauptversionen ausführlich beschrieben, einschließlich sprachspezifischer Breaking Changes. Darüber hinaus erhalten Sie schrittweise Anleitungen für eine erfolgreiche Migration Ihrer vorhandenen Funktions-App.

• Migrieren von Runtimeversion 3.x zu Version 4.x
• Migrieren von Runtimeversion 1.x zu Version 4.x

Ändern der Version von Apps in Azure

Für die Hauptversion der Runtime werden folgende Werte verwendet:

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.

Mindesterweiterungsversionen

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

Eingestellte Versionen

Diese Versionen der Functions-Runtime haben am 13. Dezember 2022 das Ende des erweiterten Supports erreicht.

Sie sollten so schnell wie möglich Ihre Apps zu Version 4.x migrieren, um vollständigen Support zu erhalten. Eine vollständige Reihe sprachspezifischer Migrationsanweisungen finden Sie unter Migrieren von Apps zu Azure Functions Version 4.x.

Apps, die Versionen 2.x und 3.x verwenden, können weiterhin über Ihre CI/CD-DevOps-Pipeline erstellt und bereitgestellt werden, und alle vorhandenen Apps werden weiterhin ohne Breaking Changes ausgeführt. Ihre Apps sind jedoch nicht für neue Features, Sicherheitspatches und Leistungsoptimierungen berechtigt. Sie können den entsprechenden Dienst nur erhalten, nachdem Sie ein Upgrade Ihrer Apps auf Version 4.x durchgeführt haben.

Das Ende des Supports für Versionen 2.x und 3.x ist auf das Ende des Supports für die Version .NET Core 3.1 zurückzuführen, die sie als Kernabhängigkeit hatten. Diese Anforderung wirkt sich auf alle Sprachen aus, die von Azure Functions unterstützt werden.

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 zwei Hauptversionen der Laufzeit. 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>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>

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

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:

Hinweise:

1. Der Support für Version 1.x der Azure Functions-Laufzeit endet am 14. September 2026. Es wird dringend empfohlen, dass Sie Ihre Apps zu Version 4.x migrieren, um vollständigen Support zu erhalten.
2. Ab Version 2.x der Runtime müssen alle Bindungen mit Ausnahme von HTTP und Timer registriert werden. Siehe Registrieren von Bindungserweiterungen.
3. Trigger werden im Plan „Verbrauch“ nicht unterstützt. Erfordert runtimegesteuerte Trigger.
4. Wird nur in Kubernetes, IoT Edge und anderen selbstgehosteten Modi unterstützt.

Funktions-App-Timeoutdauer

Die Timeoutdauer für Funktionen in einer Funktions-App wird durch die functionTimeout-Eigenschaft in der host.json-Projektdatei definiert. Diese Eigenschaft gilt speziell für Funktionsausführungen. Nachdem der Trigger die Ausführung der Funktion gestartet hat, muss die Funktion innerhalb der Timeoutdauer eine Rückgabe durchführen/reagieren. Um Timeouts zu vermeiden, ist es wichtig, robuste Funktionen zu schreiben. Weitere Informationen finden Sie unter Optimieren der Leistung und Zuverlässigkeit von Azure Functions.

Die folgende Tabelle zeigt die Standard- und Höchstwerte (in Minuten) für bestimmte Pläne:

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. Es wird keine maximale Ausführungstimeoutdauer erzwungen. Die Toleranzperiode einer Funktionsausführung beträgt jedoch 60 Minuten während der Abskalierung für Flex-Verbrauchs- und Premium-Pläne, und während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
3. Hierfür muss der App Service-Plan auf Always On festgelegt werden. Während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
4. Das Standardtimeout für Version 1.x der Functions-Host-Runtime ist unbegrenzt.
5. Wenn die Mindestanzahl von Replikaten auf Null festgelegt ist, hängt das Standardtimeout von den spezifischen Triggern ab, die in der App verwendet werden.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Lokales Codieren und Testen von Azure Functions
• Einstellen von Runtimeversionen von Azure Functions als Ziel
• Versionshinweise