Freigeben über


Unterschiede zwischen dem isolierten Arbeitsmodell und dem In-Process-Modell für .NET für Azure Functions

Es gibt zwei Ausführungsmodelle für .NET Funktionen:

Ausführungsmodell BESCHREIBUNG
Isoliertes Arbeitermodell Ihr Funktionscode wird in einem separaten .NET Arbeitsprozess ausgeführt. Wird mit unterstützten Versionen von .NET und .NET Framework verwendet. Weitere Informationen finden Sie unter Guide zum Ausführen von C#-Azure Functions im isolierten Arbeitsmodell.
In-Process-Modell Ihr Funktionscode wird im gleichen Prozess wie der Functions-Hostprozess ausgeführt. Unterstützt nur Long Term Support (LTS)-Versionen von .NET. Weitere Informationen finden Sie unter Develop C#-Klassenbibliotheksfunktionen mit Azure Functions.

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps auf das isolierte Workermodell umzustellen, um vollen Support zu erhalten.

In diesem Artikel wird der aktuelle Zustand der Funktions- und Verhaltensunterschiede zwischen den beiden Modellen beschrieben. Informationen zum Migrieren vom In-Process-Modell zum isolierten Workermodell finden Sie unter Migrate .NET Apps aus dem In-Process-Modell zum isolierten Workermodell.

Vergleichstabelle für Ausführungsmodelle

Verwenden Sie die folgende Tabelle, um Feature- und Funktionsunterschiede zwischen den beiden Modellen zu vergleichen:

Feature/Verhalten Isoliertes Workermodell Prozessinternes Modell3
Unterstützte .NET-Versionen LTS-Versionen (Long-Term Support, langfristiger Support)
STS-Versionen (Standard Term Support, Standard-Laufzeitunterstützung),
.NET Framework
Long Term Support (LTS)-Versionen, enden mit .NET 8
Erforderliche Pakete Microsoft. Azure. Functions.Worker
Microsoft. Azure. Functions.Worker.Sdk
Microsoft.NET. Sdk.Functions
Pakete für Bindungserweiterungen Microsoft. Azure. Functions.Worker.Extensions.* Microsoft. Azure. WebJobs.Extensions.*
Durable Functions Supported Supported
Modelltypen, die durch Bindungen verfügbar gemacht werden Einfache Typen
Serialisierbare JSON-Typen
Arrays/Enumerationen
Service SDK-Typen4
Einfache Typen
JSON-serialisierbare Typen
Arrays/Enumerationen
Service SDK-Typen4
HTTP-Triggermodelltypen HttpRequestData / HttpResponseData
HttpRequest / IActionResult (using ASP.NET Core integration)5
HttpRequest / IActionResult5
HttpRequestMessage / HttpResponseMessage
Ausgabebindungsinteraktionen Rückgabewerte in einem erweiterten Modell mit Folgendem:
– einzelne Ausgabe oder mehrere Ausgaben
– Ausgabearrays
Rückgabewerte (nur einzelne Ausgabe),
out-Parameter,
IAsyncCollector
Imperative Bindungen1 Nicht unterstützt – stattdessen direkt mit SDK-Typen arbeiten Supported
Abhängigkeitsinjektion Supported (verbessertes Modell, das mit .NET Ökosystem konsistent ist) Supported
Middleware Supported Nicht unterstützt
Protokollierung ILogger<T> / ILogger abgerufen von FunctionContext oder mithilfe der Abhängigkeitsinjektion An die Funktion übergebene Schnittstelle ILogger
ILogger<T> durch Abhängigkeitsinjektion
Application Insights-Abhängigkeiten Supported Supported
Abbruchtoken Supported Supported
Kaltstartdauer2 Konfigurierbare Optimierungen Optimiert
ReadyToRun Supported Supported
[Flex-Verbrauch] Supported Nicht unterstützt
.NET Aspire Vorschau Nicht unterstützt
  1. Wenn Sie mit einem Dienst interagieren müssen, der Parameter verwendet, die zur Laufzeit bestimmt sind, wird empfohlen, die entsprechenden Dienst-SDKs direkt zu verwenden, anstatt imperativer Bindungen. Die SDKs sind weniger ausführlich, decken mehr Szenarien ab und haben Vorteile bei der Fehlerbehandlung und beim Debuggen. Diese Empfehlung gilt für beide Modelle.
  2. Auf Windows könnten Kaltstartzeiten zusätzlich beeinträchtigt werden, wenn einige Vorschauversionen von .NET aufgrund des just-in-time-Ladens von Vorschauframeworks verwendet werden. Diese Auswirkung gilt sowohl für das In-Process- als auch für das isolierte Worker-Modell, kann sich aber beim Vergleich verschiedener Versionen bemerkbar machen. Diese Verzögerung für Vorschauversionen ist in Linux-Plänen nicht vorhanden.
  3. C#-Skriptfunktionen werden auch im Prozess ausgeführt und verwenden dieselben Bibliotheken wie In-Process-Klassenbibliotheksfunktionen. Weitere Informationen finden Sie in der Entwicklerreferenz Azure Functions C#-Skript (CSX).
  4. Dienst-SDK-Typen umfassen Typen aus dem Azure SDK für .NET wie BlobClient.
  5. ASP.NET Core Typen werden für .NET Framework nicht unterstützt.

Unterstützte Versionen

Versionen der Funktionslaufzeit unterstützen bestimmte Versionen von .NET. Weitere Informationen zu Funktionsversionen finden Sie unter Azure Functions Laufzeitversionen – Übersicht. Die Versionsunterstützung hängt auch davon ab, ob Ihre Funktionen prozessintern oder in einem isolierten Workerprozess ausgeführt werden.

Hinweis

Informationen zum Ändern der von Ihrer Funktions-App verwendeten Functions-Runtimeversion finden Sie unter Anzeigen und Aktualisieren der aktuellen Runtimeversion.

Die folgende Tabelle zeigt die höchste Ebene von .NET oder .NET Framework, die mit einer bestimmten Version von Funktionen verwendet werden kann.

Version der Functions-Laufzeit Isoliertes Arbeitermodell In-Process-Modell4
Functions 4.x1 .NET 105
.NET 9.0
.NET 8.0
.NET Framework 4.82
.NET 8.0
Functions 1.x3 .NET Framework 4.8

1 .NET 6 wurde zuvor auf beiden Modellen unterstützt, erreichte jedoch das Ende des offiziellen Supports am 12. November 2024. .NET 7 wurde zuvor auf dem isolierten Arbeitsmodell unterstützt, erreichte aber am 14. Mai 2024 das Ende des offiziellen Supports.

2 Der Buildvorgang erfordert auch das .NET SDK.

3 Der Support endet für Version 1.x der Azure Functions Laufzeit am 14. September 2026. Weitere Informationen finden Sie unter diese Supportankündigung. Um weiterhin uneingeschränkten Support zu erhalten, müssen Sie Ihre Apps zur Version  4.x migrieren.

4 Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Weitere Informationen finden Sie unter diese Supportankündigung. Um weiterhin uneingeschränkten Support zu erhalten, müssen Sie Ihre Apps zum Modell mit isolierten Workern migrieren.

5 Sie können nicht .NET 10 Apps unter Linux im Verbrauchsplan ausführen. Um unter Linux auszuführen, sollten Sie stattdessen den Flex-Verbrauchsplan verwenden. Schritt-für-Schritt-Migrationsanweisungen finden Sie unter Migrieren von Verbrauchsplan-Apps zum Flex-Verbrauchsplan.

Für die neuesten Nachrichten zu Azure Functions-Versionen, einschließlich der Entfernung spezifischer älterer Nebenversionen, verfolgen Sie die Ankündigungen des Azure App Service.

Nächste Schritte