Freigeben über

Übersicht über die Runtimeversionen von Azure Functions

  • Artikel

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:

Version Supportebene Beschreibung
4.x Allgemein verfügbar Empfohlene Runtimeversion für Funktionen in allen Sprachen. Informieren Sie sich über unterstützte Sprachversionen.
1.x Allgemeine Verfügbarkeit (Support endet am 14. September 2026) Wird nur für C#-Apps unterstützt, die .NET Framework verwenden müssen. Diese Version befindet sich im Wartungsmodus. Verbesserungen werden erst in späteren Versionen bereitgestellt. Der Support endet für Version 1.x am 14. September 2026. Es wird dringend empfohlen, Ihre Apps zu Version 4.x zu migrieren, die .NET Framework 4.8, .NET 8 und .NET 9 unterstützt.

Wichtig

Seit dem 13. Dezember 2022 haben Funktions-Apps, die in den Versionen 2.x und 3.x der Azure Functions-Runtime ausgeführt werden, das Ende des erweiterten Supports erreicht. Weitere Informationen finden Sie unter Eingestellte Versionen.

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.

Die folgende Tabelle zeigt die von Azure Functions unterstützten .NET-Versionen. Wählen Sie oben im Artikel Ihre bevorzugte Entwicklungssprache aus.

Die unterstützte Version von .NET hängt sowohl von Ihrer Functions-Runtimeversion als auch von Ihrem ausgewählten Ausführungsmodell ab:

Ihr Funktionscode wird in einem separaten .NET-Workerprozess ausgeführt. Verwenden Sie dazu unterstützte Versionen von .NET und .NET Framework. Weitere Informationen finden Sie unter Entwickeln von isolierten .NET-Workerprozessfunktionen.

Unterstützte Version Supportebene Erwartetes EOL-Datum für Community
.NET 9 Allgemein verfügbar 12. Mai 2026
.NET 8 Allgemein verfügbar 10. November 2026
.NET Framework 4.8.1 Allgemein verfügbar Siehe Richtlinie

.NET 6 wurde zuvor beim isolierten Workermodell unterstützt, hat aber am 12. November 2024 das Ende der offiziellen Unterstützung erreicht.

.NET 7 wurde zuvor beim isolierten Workermodell unterstützt, hat aber am 14. Mai 2024 das Ende der offiziellen Unterstützung erreicht.

Weitere Informationen finden Sie im Leitfaden zum Ausführen von Azure Functions (C#) in einem isolierten Workerprozess.

Die folgende Tabelle zeigt die für Java-Funktionen unterstützten Sprachversionen. Wählen Sie oben im Artikel Ihre bevorzugte Entwicklungssprache aus.

Unterstützte Version Supportebene Erwartetes EOL-Datum für Community
Java 21 (nur Linux) Vorschau September 2028
Java 17 Allgemein verfügbar September 2027
Java 11 Allgemein verfügbar September 2027
Java 8 Allgemein verfügbar 30. November 2026

Weitere Informationen finden Sie im Java-Entwicklerhandbuch für Azure Functions.

Die folgende Tabelle zeigt die für Node.js-Funktionen unterstützten Sprachversionen. Wählen Sie oben im Artikel Ihre bevorzugte Entwicklungssprache aus.

Unterstützte Version Supportebene Erwartetes EOL-Datum für Community
Node.js 22 Vorschau 30. April 2027
Node.js 20 Allgemein verfügbar 30. April 2026
Node.js 18 Allgemein verfügbar 30. April 2025

TypeScript wird durch die Transpilierung in JavaScript unterstützt. Weitere Informationen finden Sie im Node.js-Entwicklerhandbuch für Azure Functions.

Die folgende Tabelle zeigt die für PowerShell-Funktionen unterstützten Sprachversionen. Wählen Sie oben im Artikel Ihre bevorzugte Entwicklungssprache aus.

Unterstützte Version Supportebene Erwartetes EOL-Datum für Community
PowerShell 7.4 Allgemein verfügbar 10. November 2026
PowerShell 7.2 Allgemein verfügbar 8\. November 2024

Weitere Informationen finden Sie im PowerShell-Entwicklerhandbuch für Azure Functions.

Die folgende Tabelle zeigt die für Python-Funktionen unterstützten Sprachversionen. Wählen Sie oben im Artikel Ihre bevorzugte Entwicklungssprache aus.

Unterstützte Version Supportebene Erwartetes EOL-Datum für Community
Python 3.11 Allgemein verfügbar Oktober 2027
Python 3.10 Allgemein verfügbar Oktober 2026
Python 3.9 Allgemein verfügbar Oktober 2025
Python 3.8 Allgemein verfügbar Oktober 2024

Weitere Informationen finden Sie im Python-Entwicklerhandbuch für Azure Functions.

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.

Ändern der Version von Apps in Azure

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

Wert Runtimeziel
~4 4.x
~1 1.x

Wichtig

Ändern Sie diese App-Einstellung mit Bedacht, da hierdurch möglicherweise weitere Änderungen an App-Einstellungen und Ihrem Funktionscode nötig werden. Befolgen Sie für vorhandene Funktions-Apps die Migrationsanweisungen.

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

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": "[4.0.0, 5.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": "[4.0.0, 5.0.0)"
    }
}

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

Eingestellte Versionen

Wichtig

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.

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

Version Aktuelle Supportebene Vorherige Supportebene
3.x Nicht mehr unterstützt Allgemein verfügbar
2.x Nicht mehr unterstützt Allgemein verfügbar

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>

Wenn Sie das isolierte Workermodell verwenden, können Sie net8.0, net6.0 oder net48 als Zielframework auswählen. Sie können auch Vorschauunterstützung für net9.0 wählen. Wenn Sie das In-Process-Modell verwenden, können Sie nur net8.0 oder net6.0 auswählen, und Sie müssen die Microsoft.NET.Sdk.Functions-Erweiterung auf mindestens 4.4.0 festlegen.

.NET 7 wurde zuvor beim isolierten Workermodell unterstützt, hat aber am 14. Mai 2024 das Ende der offiziellen Unterstützung erreicht.

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:

Typ 1.x1 2.x und höher2 Trigger Eingabe Output
Blob Storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure Data Explorer ✔ ✔ ✔
Azure SQL ✔ ✔ ✔ ✔
Dapr4 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP und Webhooks ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka3 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
Redis ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Tabellenspeicherung ✔ ✔ ✔ ✔
Zeitgeber ✔ ✔ ✔
Twilio ✔ ✔ ✔

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:

Plan Standard Maximum1
Flex-Verbrauchstarif 30 Unbounded2
Premium-Plan 304 Unbounded2
Dedizierter Plan 304 Unbounded3
Container-Apps 30 Unbegrenzt5
Verbrauchstarif 5 10
  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: