Azure Funktionen zum 10. November 2026: .NET 8, .NET 9, „ PowerShell “ 7.4 und In-Process-Modell

Vier Stichtage fürAzure Functions laufen am selben Tag, dem 10. November 2026, aus: .NET 8 und .NET 9 im „Isolated Worker“-Modell, das „In-Process“-Modell selbst, das nur mit .NET 8 funktioniert, sowie „ PowerShell “ 7.4. Microsoft hat am 23. September 2026 in zwei Einträgen in den Azure Updates, in denen dazu aufgefordert wird, noch vor diesem Datum auf .NET 10 und „ PowerShell “ 7.6 umzusteigen.

Diese vier Support-Enddaten erfordern nicht denselben Aufwand. Ein Wechsel der .NET-Version im „Isolated Worker“-Modell erfordert eine Aktualisierung des Projekts, seiner Abhängigkeiten und der Anwendungskonfiguration. Der Ausstieg aus dem „In-Process“-Modell ist eine Code- migration . Und eine auf Linux im „Consumption“-Plan gehostete Anwendung muss zunächst den Plan wechseln, da dort weder .NET 10 noch „ PowerShell “ 7.6 verfügbar sind.

Daten, die am 29. September 2026 aus der Microsoft-Dokumentation entnommen wurden.

Eine zurückgezogene Version läuft weiterhin, ohne Sicherheitspatches

Die Anwendungen werden am 10. November 2026 nicht eingestellt. Die Support-Richtlinie für die Sprachstacks vonAzure Functions besagt, dass nach dem Ende der Lebensdauer eine Anwendung, die eine ausgemusterte Version verwendet, weiterhin erstellt und bereitgestellt werden kann und auf der Plattform weiterläuft. Sie erhält jedoch keine neuen Funktionen, keine Sicherheitspatches und keine Leistungsoptimierungen mehr, solange sie nicht aktualisiert wurde.

Microsoft behält sich außerdem vor, bei Bedarf und in bestimmten Fällen die Anzahl der diesen Anwendungen zugewiesenen Instanzen auf maximal eine Instanz zu begrenzen. Schließlich verlangt der Microsoft-Support ein Upgrade, bevor Maßnahmen an einer Anwendung ergriffen werden können, die auf einer nicht unterstützten Version läuft.

Warum .NET 9 kein Zwischenschritt ist

.NET 9 ist eine STS-Version. Das Ende des Supports war ursprünglich für den 12. Mai 2026 angekündigt worden; das .NET-Team hat die Supportdauer für STS-Versionen ab .NET 9 anschließend auf 24 Monate verlängert, wodurch das Ende des Supports auf den 10. November 2026 fällt – denselben Tag wie bei .NET 8. Eine Anwendung, die von .NET 8 auf .NET 9 umgestellt würde, wäre somit zum gleichen Zeitpunkt nicht mehr unterstützt.

Die Zielversion ist .NET 10, eine LTS-Version, die am 11. November 2025 veröffentlicht wird und bis zum 14. November 2028 unterstützt wird. Der Leitfaden „ migration “ von Microsoft nennt zwei Zielversionen für das „Isolated Worker“-Modell: .NET 10, wenn die Anwendung und ihre Abhängigkeiten unter .NET laufen können, und .NET Framework 4.8, wenn sie von Bibliotheken oder „API “ abhängen, die spezifisch für das .NET Framework sind.

Das In-Process-Modell: Vor der Umstellung auf eine neuere .NET-Version auf „isolated worker“ umstellen

Das In-Process-Modell unterstützt ausschließlich .NET 8. Damit eine Anwendung Azure In-Process-Functions auf eine neuere Version von .NET umgestellt werden kann, muss sie zunächst auf das Isolated-Worker-Modell migriert werden. Microsoft stellt ein Skript bereit Azure PowerShell zur Verfügung, das im aktuellen Abonnement die Anwendungen auflistet, die noch im In-Process-Modell laufen:

$FunctionApps = Get-AzFunctionApp $AppInfo = @{} foreach ($App in $FunctionApps) { if ($App.Runtime -eq 'dotnet') { $AppInfo.Add($App.Name, $App.Runtime) } } $AppInfo

Das Skript verarbeitet das in Azure PowerShell. Um ein anderes zu überprüfen, führen Sie zunächst Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>'.

Die „ migration “ wirkt sich an mehreren Stellen auf das Projekt aus. Das Attribut Sdk des Elements Project geht über zu Azure.Functions.Sdk/1.0.0. Eine Datei Program.cs wird dem Projekt hinzugefügt und ersetzt die Datei, die das Attribut trägt FunctionsStartup, im Allgemeinen Startup.cs. Auch die Signaturen der Funktionen ändern sich: Im Allgemeinen erhalten die Eingabe-Binding-Attribute das Suffix Input und die Ausgabedateien das Suffix Output, wie CosmosDBInput oder QueueOutput. Was die Konfiguration betrifft, so ist der Anwendungsparameter FUNCTIONS_WORKER_RUNTIME geht von dotnet an dotnet-isolated. Für eine .NET 10-Zielumgebung gibt Microsoft an, dass der .NET Upgrade Assistant viele dieser Änderungen automatisch vornehmen kann.

System.Text.Json ignoriert Newtonsoft.Json-Attribute, ohne dies zu melden

Das In-Process-Modell verwendete Newtonsoft.Json; das Isolated-Worker-Modell verwendet standardmäßig System.Text.Json. System.Text.Json ignoriert Attribute von Newtonsoft.Json wie beispielsweise [JsonProperty] und [JsonIgnore], und ordnet der betreffenden Eigenschaft dann ihren Standardwert zu, ohne einen Fehler zu melden. Eine Funktion, die eine Nachricht ausliest, deren Feldnamen durch [JsonProperty] erhält daher diese nicht angegebenen Eigenschaften, ohne dass dabei beim Verknüpfen ein Fehler auftritt.

Microsoft schlägt zwei Korrekturen vor: Ersetzen Sie diese Attribute durch ihre Entsprechungen in System.Text.Json, wie zum Beispiel [JsonPropertyName], oder Newtonsoft.Json für die Schicht konfigurieren, die diese Daten verarbeitet.

FUNCTIONS_WORKER_RUNTIME und Veröffentlichung: zwei Neustarts und dazwischen der Fehler AZFD0013

Bei Azureerfordert die Umschaltung zwei Schritte: erstens FUNCTIONS_WORKER_RUNTIME an dotnet-isolated, und das migrierte Projekt veröffentlichen. Jeder startet die Anwendung neu. Dazwischen stimmen der bereitgestellte Code und die konfigurierte Laufzeitumgebung nicht überein, und die Anwendung gibt den Fehler zurück AZFD0013 bis zur zweiten Operation.

Microsoft empfiehlt daher, einen Staging-Slot zu nutzen: Dort werden beide Änderungen vorgenommen, es wird überprüft, ob die Fehler behoben sind und die Anwendung funktioniert, und anschließend wird der Slot in einem einzigen Update mit dem Produktions-Slot ausgetauscht. FUNCTIONS_WORKER_RUNTIME darf nicht als Slot-Parameter gekennzeichnet werden. Eine CI/CD-Pipeline oder eine andere automatisierte Bereitstellung der Anwendung muss ebenfalls aktualisiert werden, um dotnet-isolated und die richtige .NET-Version auswählen.

Die Art der Unterbringung bestimmt die Reihenfolge der Vorgänge

Unter Linux im „Consumption“-Tarif ist .NET 9 die letzte unterstützte .NET-Version, und Microsoft fügt keine nachfolgenden Versionen hinzu: Eine .NET 10-Anwendung kann dort nicht ausgeführt werden. Das Gleiche gilt für „ PowerShell “, dessen Version 7.4 die letzte ist, die in diesem Tarif verfügbar ist. Vor dem Umstieg auf .NET 10 oder „ PowerShell “ 7.6 muss eine solche Anwendung daher auf den „Flex Consumption“-Tarif migriert werden. Das Hosting unter Linux im Consumption-Tarif soll seinerseits zum 30. September 2028 eingestellt werden und erhält weder neue Funktionen noch neue Sprachversionen mehr.

Eine In-Process-Anwendung auf dieser Ebene vereint somit den Wechsel von Modell, Plan und Version. Flex Consumption unterstützt den Stack nicht dotnet des In-Process-Modells, und Microsoft verlangt, zunächst auf das Isolated-Worker-Modell umzustellen. Da .NET 10 unter Linux im Consumption-Plan nicht läuft, wechselt die Anwendung zunächst den Plan, bevor sie auf .NET 10 umgestellt werden kann.

Die angekündigte Einstellung betrifft Linux: Microsoft weist darauf hin, dass Anwendungen im „Consumption“-Tarif unter Windows derzeit nicht betroffen sind. „ PowerShell “ 7.6 wird in allen Tarifen außer „Linux Consumption“ unterstützt, insbesondere in den Tarifen „Premium“ und „Dedicated“ unter Windows sowie in den Tarifen „Linux“, „ Windows “ Consumption und „Flex Consumption“.

Zwei Aufträge Azure CLI erstellen eine Bestandsaufnahme. az functionapp flex-migration list analysiert das Abonnement und gibt zwei Listen zurück, eligible_apps und ineligible_apps, zusammen mit der Begründung für jede Inkompatibilität. Es werden nur Anwendungen im „Consumption“-Tarif unter Linux bewertet; um den Tarif aller Anwendungen zu erfahren, stellt Microsoft az functionapp list --query "[].{name:name, sku:sku}" -o table, wobei der Wert Dynamic bezeichnet den Tarif „Consumption“.

Flex Consumption bietet keine Bereitstellungsslots an

Die Verfahren von Microsoft für die In-Process- migration und für Versionswechsel basieren auf einem Staging-Slot. Flex Consumption unterstützt derzeit jedoch keine Deployment-Slots. Microsoft empfiehlt, den aktualisierten Code in einer Nicht-Produktions-Anwendung zu überprüfen, und verweist auf die „Rolling-Update“-Strategie für die Bereitstellung in einer laufenden Anwendung. Das Vorhandensein eines Slots blockiert die „ migration “ zwar nicht, jedoch muss vor der Umschaltung festgelegt werden, wie die Anwendung ohne diesen Slot getestet und bereitgestellt werden soll.

Die Stack-Version ändern und anschließend überprüfen

Mit Ausnahme von „Flex Consumption“ wird die Stack-Version in der Anwendungskonfiguration geändert, sobald der Code aktualisiert und veröffentlicht wurde – vorzugsweise auf dem Staging-Slot, sofern vorhanden. Mit Azure CLI:

• unter Windows, az functionapp config set --net-framework-version "v<VERSION>.0" für .NET und --powershell-version "<VERSION>" für PowerShell ;
• unter Linux, im Premium-, Dedicated- oder Consumption-Tarif, az functionapp config set --linux-fx-version "<LANGUAGE|VERSION>", mit dem Wert, den az functionapp list-runtimes --os linux für die betreffende Batterie.

Jede Bestellung dauert --name, --resource-group und für einen Steckplatz --slot. Der tatsächlich angewendete Wert lässt sich mit az functionapp show, auf siteConfig.netFrameworkVersion, siteConfig.linuxFxVersion oder siteConfig.powerShellVersion. Überprüfen Sie außerdem, ob FUNCTIONS_EXTENSION_VERSION ist ~4 : Microsoft geht davon aus, dass die Anwendung bereits die Version 4.x der Functions-Laufzeitumgebung nutzt, und verweist für frühere Versionen auf die entsprechenden Anleitungen zur „ migration “.

Ohne Slot führt die Änderung zu einem Neustart der Anwendung in der Produktionsumgebung: Die Anwendung ist für einen kurzen Zeitraum – in der Regel 30 bis 60 Sekunden – nicht verfügbar, laufende Anfragen werden unterbrochen und neue Anfragen schlagen fehl, bis die Anwendung neu gestartet ist. Microsoft empfiehlt in diesem Fall ein Wartungsfenster.

Bei „Flex Consumption“ sind diese Eigenschaften veraltet und sollten nicht verwendet werden. In der Referenz zu den Anwendungsparametern heißt es: LinuxFxVersion, netFrameworkVersion und powerShellVersion werden dort ersetzt durch functionAppConfig.runtime, und dass FUNCTIONS_EXTENSION_VERSION wird dort von der Plattform verwaltet und muss nicht manuell eingestellt werden.

PowerShell 7.4, in Azure „Funktionen“ und anderswo

Unter Azure „Functions“ werden die beiden Versionen „ PowerShell “ 7.6 und 7.4 unterstützt, wobei der Support für 7.4 am 10. November 2026 endet. „ PowerShell “ 7.6, eine am 18. März 2026 auf Basis von .NET 10 veröffentlichte LTS-Version, wird bis zum 14. November 2028 unterstützt.

Das Datum liegt außerhalb Azure Funktionen. Der Lebenszyklus von „ PowerShell “ folgt dem der jeweiligen .NET-Version, auf der die jeweilige Version basiert: „ PowerShell “ 7.4 basiert auf .NET 8, und „ PowerShell “ 7.5, das auf .NET 9 basiert, wird am selben Tag eingestellt. Betreibenskripte, die unter PowerShell 7.4 oder 7.5 auf Servern, in geplanten Aufgaben oder auf Build-Agenten ausgeführt werden, sind daher ebenfalls betroffen. Windows PowerShell , eine Komponente von Windows, folgt hingegen dem Lebenszyklus von Windows.

Der 10. November 2026 ist auch für .NET 8 und „ PowerShell “ 7.4 im Zeitplan für das Ende des Supports im Herbst 2026 aufgeführt, in dem detailliert aufgeführt ist, was am 13. Oktober 2026 ausläuft.

Unsere Lektüre

Wir würden diese vier Support-Endtermine nicht als einen einzigen Termin behandeln, da sie einen unverhältnismäßig hohen Aufwand erfordern. Eine Anwendung, die bereits als „Isolated Worker“ unter .NET 8 läuft und im Premium-, Dedicated- oder Flex-Consumption-Modell gehostet wird, erfordert einen Versionswechsel und eine Testreihe. Eine In-Process-Anwendung unter Linux im „Consumption“-Tarif vereint das Ausführungsmodell, den Hosting-Tarif und die .NET-Version; sobald sie auf „Flex Consumption“ umgestellt ist, steht kein Slot mehr zur Verfügung, um die verbleibenden Änderungen abzusichern.

Die Bestandsaufnahme erfolgt also anhand von zwei Kriterien: dem Wert von FUNCTIONS_WORKER_RUNTIME und das Hosting-Paket. Das Skript Azure PowerShell von Microsoft und der Befehl az functionapp list reichen aus, um es einzurichten, und wir öffnen zunächst die Anwendungen dotnet in der Draufsicht Dynamic unter Linux. Für diese führen wir vor der Planänderung die „ migration “ zum Modell „isolated worker“ durch, solange der Staging-Slot noch vorhanden ist.

Wir zielen direkt auf .NET 10 ab, ohne einen Zwischenstopp bei .NET 9, dessen Unterstützung am selben Tag ausläuft. Und in einer In-Process- migration testen wir zunächst die Serialisierung anhand echter Nachrichten: Die Bindung meldet keine Fehler, und die Funktion erhält diese Eigenschaften mit ihren Standardwerten.

Was zu überprüfen ist

• Die Liste der Anwendungen, darunter FUNCTIONS_WORKER_RUNTIME ist dotnet, die durch das Skript Azure PowerShell von Microsoft, Abonnement für Abonnement.
• Der Hosting-Plan jeder Anwendung, insbesondere derjenigen in Dynamic unter Linux, die auf .NET oder PowerShell  laufen: Sie müssen über Flex Consumption laufen, um .NET 10 oder PowerShell 7.6 zu erreichen.
• Anwendungen, die einen Bereitstellungs-Slot nutzen und auf Flex Consumption umgestellt werden müssen, für die eine andere Test- und Bereitstellungsmethode festgelegt werden muss.
• Typen, die über Funktionen verknüpft sind, die Newtonsoft.Json-Attribute tragen, wie beispielsweise [JsonProperty] oder [JsonIgnore].
• CI/CD-Pipelines und Infrastrukturmodelle, die festlegen, FUNCTIONS_WORKER_RUNTIME oder die Version des Stacks.
• Ohne Flex Consumption beträgt der Wert von FUNCTIONS_EXTENSION_VERSION, das lauten muss ~4.
• PowerShell -Anwendungen und -Skripte der Versionen 7.4 oder 7.5, in Azure funktionieren wie auf den Servern und den Build-Agenten.

Quellen von Microsoft

• Einstellung: Der Support für .NET 8 und .NET 9 endet am 10. November 2026
• Einstellung: Der Support für „ PowerShell “ 7.4 endet am 10. November 2026
• Azure Richtlinie zur Unterstützung von Funktionssprachenstapeln
• Unterstützte Sprachen in Azure Funktionen
• Migration von C#-Anwendungen vom In-Process-Modell zum isolierten Worker-Modell
• Anleitung zum Ausführen von C# Azure im isolierten Worker-Modell
• Versionen des Sprachstacks aktualisieren in Azure Funktionen
• Referenz zu den App-Einstellungen für Azure Funktionen
• Apps des „Consumption Plan“ in den „Flex Consumption Plan“ migrieren
• Azure Funktionen – Hosting von Verbrauchsplänen
• Richtlinie zur Unterstützung von .NET und .NET Core
• PowerShell Support-Lebenszyklus