Freigeben über

Migrieren von C#-Apps vom In-Process-Modell zum isolierten Workermodell

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, indem Sie die Anweisungen in diesem Artikel befolgen.

In diesem Artikel werden Sie durch den Prozess der sicheren Migration Ihrer .NET-Funktions-Apps vom In-Process-Modell zum isolierten Workermodell geführt. Informationen über die wesentlichen Unterschiede zwischen diesen Modellen finden Sie im Vergleich des Ausführungsmodus.

In diesem Leitfaden wird davon ausgegangen, dass Ihre App mit Version 4.x der Functions-Runtime ausgeführt wird. Wenn nicht, sollten Sie die folgenden Leitfäden verwenden, um die Hostversion zu aktualisieren. Diese Leitfäden zur Migration der Hostversion unterstützen Sie auch bei der Migration zum Workermodell „Isoliert“.

Bei entsprechender Unterstützung nutzt dieser Artikel die ASP.NET Core-Integration im isolierten Workermodell. Dadurch wird die Leistung verbessert, und es wird ein vertrautes Programmiermodell bereitgestellt, wenn Ihre App HTTP-Trigger verwendet.

Identifizieren zu migrierender Funktions-Apps

Verwenden Sie das folgende Azure PowerShell-Skript, um eine Liste der Funktions-Apps in Ihrem Abonnement zu erstellen, die derzeit das In-Process-Modell verwenden.

Das Skript verwendet das Abonnement, dessen Verwendung derzeit in Azure PowerShell konfiguriert ist. Sie können das Abonnement ändern, indem Sie zuerst Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' ausführen und <YOUR SUBSCRIPTION ID> durch die ID des Abonnements, das Sie auswerten möchten, ersetzen.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Auswählen der .NET-Zielversion

Für Version 4.x der Functions-Runtime wird bei Verwendung des In-Process-Modells .NET 6 oder .NET 8 als Zielumgebung für Ihre .NET-Funktions-App verwendet.

Wenn Sie Ihre Funktions-App migrieren, haben Sie die Möglichkeit, die Zielversion von .NET auszuwählen. Sie können Ihr C#-Projekt auf eine der folgenden Versionen von .NET aktualisieren, die von der Functions-Version 4.x unterstützt werden:

.NET-Version Releasetyp der offiziellen .NET-Supportrichtlinie Functions-Prozessmodell1,2
.NET 10 LTS (Ende des Supports vom 14. November 2028) Isoliertes Workermodell
.NET 9 STS (Ende des Supports vom 10. November 2026)3 Isoliertes Workermodell
.NET 8 LTS (Ende des Supports am 10. November 2026) Isoliertes Workermodell,
In-Process-Modell2
.NET Framework 4.8 Siehe Politik Isoliertes Workermodell

1 Das isolierte Workermodell unterstützt die Versionen LTS (Long Term Support) und STS (Standard Term Support) von .NET sowie .NET Framework. Das In-Process-Modell unterstützt nur LTS-Releases von .NET, endend mit .NET 8. Einen umfassenden Feature- und Funktionsvergleich zwischen den beiden Modellen finden Sie unter Unterschiede zwischen einem In-Process- und einem isolierten Workerprozess in .NET-Azure Functions.

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

3 .NET 9 hatte zuvor ein erwartetes End-of-Support-Datum vom 12. Mai 2026. Im .NET 9-Dienstfenster erweiterte das .NET-Team den Support für STS-Versionen auf 24 Monate, beginnend mit .NET 9. Weitere Informationen finden Sie im Blogbeitrag.

Tipp

Es wird empfohlen, für das isolierte Workermodell ein Upgrade auf .NET 8 durchzuführen. Dies bietet einen schnellen Migrationspfad zur vollständig veröffentlichten Version mit dem längsten Supportfenster von .NET.

Diese Anleitung enthält keine spezifischen Beispiele für .NET 10 (Vorschauversion) oder .NET 9. Wenn Sie eine dieser Versionen als Ziel verwenden müssen, können Sie die .NET 8-Beispiele anpassen.

Vorbereiten der Migration

Bevor Sie eine App zum Workermodell „Isoliert“ migrieren, sollten Sie den Inhalt dieses Leitfadens gründlich überprüfen. Sie sollten sich auch mit den Features des Workermodells „Isoliert“ und den Unterschieden zwischen den beiden Modellen vertraut machen.

So migrieren Sie die Anwendung

  1. Führen Sie die unter Migrieren Ihres lokalen Projekts beschriebenen Schritte aus, um Ihr lokales Projekt zum Workermodell „Isoliert“ zu migrieren.
  2. Nachdem Sie Ihr Projekt migriert haben, testen Sie die App lokal und umfassend mit Version 4.x der Azure Functions Core Tools.
  3. Aktualisieren Sie Ihre Funktions-App in Azure auf das isolierte Workermodell.

Migrieren Ihres lokalen Projekts

In diesem Abschnitt werden die verschiedenen Änderungen beschrieben, die Sie an Ihrem lokalen Projekt vornehmen müssen, um es auf das isolierte Workermodell umzustellen. Einige der Schritte variieren je nach verwendeter .NET-Zielversion. Verwenden Sie die Registerkarten zur Auswahl der Anweisungen, die Ihrer gewünschten Version entsprechen.

Tipp

Wenn Sie zu einer LTS- oder STS-Version von .NET wechseln, kann der .NET-Upgrade-Assistent verwendet werden, um viele der in den folgenden Abschnitten beschriebenen Änderungen automatisch durchzuführen.

Zuerst konvertieren Sie die Projektdatei und aktualisieren Ihre Abhängigkeiten. Dabei werden Buildfehler für das Projekt angezeigt. In den folgenden Schritten nehmen Sie die entsprechenden Änderungen vor, um diese Fehler zu entfernen.

Projektdatei

Das folgende Beispiel ist eine CSPROJ-Projektdatei, die .NET 8 in Version 4.x verwendet:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Verwenden Sie eins der folgenden Verfahren, um diese XML-Datei für die Ausführung im isolierten Workermodell zu aktualisieren:

Bei diesen Schritten wird ein lokales C#-Projekt vorausgesetzt; Wenn Ihre App stattdessen C#-Skript (CSX-Dateien ) verwendet, sollten Sie in das Projektmodell konvertieren , bevor Sie fortfahren.

Die folgenden Änderungen sind in der CSPROJ-XML-Projektdatei erforderlich:

  1. Legen Sie den Wert von PropertyGroup fest. TargetFramework in net8.0.

  2. Legen Sie den Wert von PropertyGroup fest. AzureFunctionsVersion in v4.

  3. Fügen Sie das folgende OutputType-Element PropertyGroup hinzu:

    <OutputType>Exe</OutputType>

  4. Ersetzen Sie in der Liste ItemGroup. PackageReference den Paketverweis durch Microsoft.NET.Sdk.Functions mit den folgenden Verweisen:

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

    Notieren Sie sich alle Verweise auf andere Pakete in den Microsoft.Azure.WebJobs.*-Namespaces. Diese Pakete werden in einem späteren Schritt ersetzt.

  5. Fügen Sie die folgende neue ItemGroup hinzu:

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Nachdem Sie diese Änderungen vorgenommen haben, sollte Ihr aktualisiertes Projekt wie das folgende Beispiel aussehen:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Die Änderung des Ziel-Frameworks Ihres Projekts kann auch Änderungen an Teilen Ihrer Toolchain außerhalb des Projektcodes erfordern. In VS Code müssen Sie zum Beispiel u. U. die Erweiterungseinstellungen azureFunctions.deploySubpath über die Benutzereinstellungen oder die Projektdatei .vscode/settings.json aktualisieren. Prüfen Sie, ob Abhängigkeiten von der Framework-Version bestehen, die außerhalb Ihres Projektcodes, als Teil von Buildschritten oder einer CI/CD-Pipeline, existieren könnten.

Paketverweise

Bei der Migration zum isolierten Workermodell müssen Sie die Pakete ändern, auf die Ihre Anwendung verweist.

Falls noch nicht geschehen, aktualisieren Sie Ihr Projekt, um auf die neuesten stabilen Versionen der folgenden Komponenten zu verweisen:

Abhängig von den Triggern und Bindungen, die Ihre App verwendet, muss Ihre App möglicherweise auf andere Pakete verweisen. In der folgenden Tabelle sind die Ersetzungen für einige der am häufigsten verwendeten Erweiterungen aufgeführt:

Szenario Änderungen an Paketverweisen
Trigger mit Timer Hinzufügen
Microsoft.Azure.Functions.Worker.Extensions.Timer
Speicherbindungen Replace
Microsoft.Azure.WebJobs.Extensions.Storage
durch
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues und
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blobbindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Warteschlangenbindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabellenbindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.Tables
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.CosmosDB
und/oder
Microsoft.Azure.WebJobs.Extensions.DocumentDB
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.ServiceBus
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.EventHubs
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.EventGrid
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.SignalRService
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Langlebige Funktionen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.DurableTask
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Langlebige Funktionen
(SQL-Speicheranbieter)		 Ersetzen Sie Verweise auf
Microsoft.DurableTask.SqlServer.AzureFunctions
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Langlebige Funktionen
(Netherite-Speicheranbieter)		 Ersetzen Sie Verweise auf
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.SendGrid
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.Kafka
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ-Bindungen Ersetzen Sie Verweise auf
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
durch die neueste Version von
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Abhängigkeitsinjektion
und Startkonfiguration		 Entfernen Sie Verweise auf
Microsoft.Azure.Functions.Extensions
(Das isolierte Workermodell stellt diese Funktionalität standardmäßig bereit.)

Eine vollständige Liste der zu berücksichtigenden Erweiterungen finden Sie unter Unterstützte Bindungen, und vollständige Installationsanweisungen für das isolierte Prozessmodell finden Sie in der Dokumentation der jeweiligen Erweiterung. Stellen Sie sicher, dass Sie die neueste stabile Version aller Pakete installieren, die Sie als Ziel verwenden.

Tipp

Alle Änderungen an Erweiterungsversionen während dieses Vorgangs erfordern möglicherweise, dass Sie auch Ihre host.json-Datei aktualisieren. Lesen Sie unbedingt die Dokumentation der einzelnen Erweiterungen, die Sie verwenden. Bei der Service Bus-Erweiterung gibt es beispielsweise Änderungen an der Struktur zwischen den Versionen 4.x und 5.x. Weitere Informationen finden Sie unter Azure Service Bus-Bindungen für Azure Functions.

Ihre isolierte Workermodellanwendung darf auf keine Pakete in den Microsoft.Azure.WebJobs.*-Namespaces oder in Microsoft.Azure.Functions.Extensions verweisen. Wenn noch Verweise auf diese vorhanden sind, sollten Sie sie entfernen.

Tipp

Ihre App kann auch von Azure SDK-Typen abhängig sein, entweder als Teil Ihrer Trigger und Bindungen oder als eigenständige Abhängigkeit. Sie sollten die Gelegenheit nutzen, um auch diese zu aktualisieren. Die neuesten Versionen der Functions-Erweiterungen können mit den neuesten Versionen des Azure SDK für .NET verwendet werden, wobei fast alle Pakete in der Form Azure.* vorliegen.

Datei „program.cs“

Bei der Migration zur Ausführung in einem isolierten Workerprozess müssen Sie ihrem Projekt die Datei Program.cs mit dem folgenden Inhalt hinzufügen:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Dieses Beispiel umfasst ASP.NET Core-Integration, um die Leistung zu verbessern und ein vertrautes Programmiermodell bereitzustellen, wenn Ihre App HTTP-Trigger verwendet. Wenn Sie nicht beabsichtigen, HTTP-Trigger zu verwenden, können Sie den Aufruf ConfigureFunctionsWebApplication durch einen Aufruf ConfigureFunctionsWorkerDefaultsersetzen. In diesem Fall können Sie den Verweis auf Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore aus der Projektdatei entfernen. Um jedoch die beste Leistung zu erzielen, sollten Sie auch für Funktionen mit anderen Triggertypen für FrameworkReference ASP.NET Core beibehalten.

Die Datei Program.cs ersetzt jede Datei mit dem Attribut FunctionsStartup. Diese ist in der Regel eine Datei vom Typ Startup.cs. An den Stellen, an denen Ihr FunctionsStartup Code auf IFunctionsHostBuilder.Services verweisen würde, können Sie stattdessen Anweisungen innerhalb der .ConfigureServices()-Methode der HostBuilder in Ihrer Program.cs hinzufügen. Weitere Informationen zum Arbeiten mit Program.cs finden Sie unter "Start- und Konfiguration " im Leitfaden zum isolierten Arbeitsmodell.

Die zuvor beschriebenen Standardbeispiele Program.cs umfassen das Einrichten von Application Insights. In Ihrem Program.cs müssen Sie auch alle Protokollfilter konfigurieren, die für Protokolle gelten sollten, die aus Code in Ihrem Projekt stammen. Im isolierten Workermodell steuert die dateihost.json nur Ereignisse, die von der Hostlaufzeit der Funktionen ausgegeben werden. Wenn Sie in Program.cs keine Filterregeln konfigurieren, treten möglicherweise Unterschiede auf den Protokollebenen für verschiedene Kategorien in Ihren Telemetriedaten auf.

Obwohl Sie benutzerdefinierte Konfigurationsquellen als Teil des HostBuilderProjekts registrieren können, gelten diese in ähnlicher Weise nur für Code in Ihrem Projekt. Die Plattform benötigt außerdem Trigger- und Bindungskonfiguration, und dies sollte über die Anwendungseinstellungen, Key Vault-Verweise oder App-Konfigurationsreferenzfeatures bereitgestellt werden.

Nachdem Sie alles von einer beliebigen vorhandenen FunctionsStartup in die Program.cs Datei verschoben haben, können Sie das FunctionsStartup Attribut und die Klasse löschen, auf die sie angewendet wurde.

Funktionssignaturänderungen

Einige wichtige Schlüsseltypen ändern sich vom In-Process-Model und dem isolierten Workermodell. Viele davon beziehen sich auf die Attribute, Parameter und Rückgabetypen, aus denen die Funktionssignatur besteht. Für jede Ihrer Funktionen müssen Sie folgende Änderungen vornehmen:

  • Das Funktionsattribute, das auch den Namen der Funktion festlegt
  • Wie die Funktion ILogger/ILogger<T> abruft
  • Trigger- und Bindungsattribute und -parameter

Im restlichen Teil dieses Abschnitts werden die einzelnen Schritte beschrieben.

Funktionsattribute

Das Function-Attribut wird im Workermodell „Isoliert“ durch das FunctionName-Attribut ersetzt. Das neue Attribut weist dieselbe Signatur auf und der einzige Unterschied liegt im Namen. Sie können daher einfach eine Zeichenfolgenersetzung für Ihr Projekt durchführen.

Protokollierung

Im In-Process-Modell können Sie für Ihre Funktion einen zusätzlichen ILogger-Parameter hinzufügen, oder Sie können die Abhängigkeitsinjektion verwenden, um ILogger<T> abzurufen. Wenn Ihre App bereits die Abhängigkeitsinjektion verwendet hat, funktionieren dieselben Mechanismen im Workermodell „Isoliert“.

Für alle Funktionen, die auf dem ILogger-Methodenparameter basieren, müssen Sie jedoch eine Änderung vornehmen. Es wird empfohlen, eine Abhängigkeitsinjektion zu verwenden, um ILogger<T> zu erhalten. Führen Sie die folgenden Schritte aus, um den Protokollierungsmechanismus der Funktion zu migrieren:

  1. Fügen Sie in der Funktionsklasse eine private readonly ILogger<MyFunction> _logger;-Eigenschaft hinzu, die MyFunction mit dem Namen der Funktionsklasse ersetzt.

  2. Erstellen Sie einen Konstruktor für Ihre Funktionsklasse, der ILogger<T> als Parameter verwendet:

    public MyFunction(ILogger<MyFunction> logger) {
    _logger = logger;
}

    Ersetzen Sie beide Instanzen von MyFunction im obigen Codeschnipsel durch den Namen Ihrer Funktionsklasse.

  3. Ersetzen Sie zum Protokollieren von Vorgängen im Funktionscode Verweise auf den ILogger-Parameter durch _logger.

  4. Entfernen Sie den ILogger-Parameter aus der Funktionssignatur.

Weitere Informationen finden Sie unter Protokollierung im isolierten Workermodell.

Trigger- und Bindungsänderungen

Wenn Sie Ihre Paketverweise in einem vorherigen Schritt geändert haben, haben Sie Fehler für die Trigger und Bindungen eingeführt, die Sie jetzt beheben können:

  1. Entfernen Sie alle using Microsoft.Azure.WebJobs;-Anweisungen.

  2. Fügen Sie eine using Microsoft.Azure.Functions.Worker;-Anweisung hinzu.

  3. Ändern Sie für jedes Bindungsattribut den Namen des Attributs wie in der Referenzdokumentation angegeben, welche Sie im Index der unterstützten Bindungen finden können. Im Allgemeinen ändern sich die Attributnamen wie folgt:

    • Trigger behalten in der Regel ihre Benennung. QueueTrigger ist beispielsweise der Attributname für beide Modelle.
    • Bei Eingabebindungen muss in der Regel ihrem Namen Input hinzugefügt werden. Wenn Sie z. B. das CosmosDB-Eingabebindungsattribut im In-Process-Modell verwendet haben, wäre das Attribut jetzt CosmosDBInput.
    • Bei Ausgabebindungen muss in der Regel ihrem Namen Output hinzugefügt werden. Wenn Sie z. B. das Queue-Ausgabebindungsattribut im In-Process-Modell verwendet haben, wäre das Attribut jetzt QueueOutput.

  4. Aktualisieren Sie die Attributparameter so, dass sie die Version des isolierten Workermodells widerspiegeln, wie in der Referenzdokumentation der Bindung angegeben.

    Im Prozessmodell wird beispielsweise eine Blob-Ausgabebindung durch ein [Blob(...)]-Attribut dargestellt, das eine Access-Eigenschaft enthält. Im isolierten Workermodell wäre das Blob-Ausgabe-Attribut [BlobOutput(...)]. Für die Bindung ist die Access-Eigenschaft nicht mehr erforderlich, sodass der Parameter entfernt werden kann. [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] würde also [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")] werden.

  5. Ausgabebindungen aus der Funktionsparameterliste verschieben. Wenn Sie nur über eine Ausgabebindung verfügen, können Sie diese auf den Rückgabetyp der Funktion anwenden. Wenn Sie über mehrere Ausgaben verfügen, erstellen Sie eine neue Klasse mit Eigenschaften für jede Ausgabe, und wenden Sie die Attribute auf diese Eigenschaften an. Weitere Informationen finden Sie unter Mehrere Ausgabebindungen.

  6. In der Referenzdokumentation jeder Bindung finden Sie die Typen, an die sie eine Bindung vornehmen können. In einigen Fällen müssen Sie den Typ möglicherweise ändern. Bei Ausgabebindungen können Sie diese durch Bindung an ein Array des Zieltyps ersetzen, wenn die in-Process-Modellversion eine IAsyncCollector<T> verwendet hat: T[]. Sie können auch erwägen, die Ausgabebindung durch ein Clientobjekt für den Dienst zu ersetzen, den er darstellt, entweder als Bindungstyp für eine Eingabebindung, falls verfügbar, oder indem Sie selbst einen Client einfügen.

  7. Wenn Ihre Funktion einen IBinder-Parameter enthält, entfernen Sie ihn. Ersetzen Sie die Funktionalität durch ein Clientobjekt für den Dienst, den es darstellt, entweder als Bindungstyp für eine Eingabebindung, falls verfügbar, oder indem Sie selbst einen Client einfügen.

  8. Aktualisieren Sie den Funktionscode so, dass er mit allen neuen Typen funktioniert.

Datei „local.settings.json“

Die Datei local.settings.json wird nur bei lokaler Ausführung verwendet. Weitere Informationen finden Sie unter Datei für lokale Einstellungen.

Wenn Sie von der prozessinternen Ausführung zur Ausführung in einem isolierten Workerprozess migrieren, müssen Sie den FUNCTIONS_WORKER_RUNTIME-Wert in dotnet-isolated ändern. Aktualisieren Sie die Datei local.settings.json, sodass sie mindestens die folgenden Elemente enthält:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Der Wert für AzureWebJobsStorage kann unterschiedlich sein. Sie müssen den Wert nicht im Rahmen der Migration ändern.

Datei „host.json“

An der host.json-Datei müssen keine Änderungen vorgenommen werden. Wenn Ihre Application Insights-Konfiguration in dieser Datei jedoch aus Ihrem Projekt mit In-Process-Modell stammt, sollten Sie zusätzliche Änderungen an der Datei Program.cs vornehmen. Die Datei host.json steuert nur die Protokollierung der Functions-Hostruntime, und im Modell mit isolierten Workern stammen einige dieser Protokolle direkt aus Ihrer Anwendung, sodass Sie mehr Kontrolle erhalten. Ausführliche Informationen zum Filtern dieser Protokolle finden Sie unter Verwalten von Protokollebenen im Modell mit isolierten Workern.

Weitere Codeänderungen

In diesem Abschnitt werden weitere Codeänderungen genannt, die während der Migration berücksichtigt werden müssen. Diese Änderungen werden von allen Anwendungen nicht benötigt, aber Sie sollten bewerten, ob sie für Ihre Szenarien relevant sind.

JSON-Serialisierung

Standardmäßig verwendet das isolierte Workermodell System.Text.Json für die JSON-Serialisierung . Informationen zum Anpassen von Serialisierungsoptionen oder zum Wechseln zu JSON.NET (Newtonsoft.Json) finden Sie unter Anpassen der JSON-Serialisierung.

Application Insights: Protokollebenen und -filterung

Protokolle können sowohl von der Functions-Hostrumtime als auch von Code in Ihrem Projekt an Application Insights gesendet werden. Mit demhost.json können Sie Regeln für die Hostprotokollierung konfigurieren, aber um Protokolle aus Ihrem Code zu steuern, müssen Sie Filterregeln als Teil Ihrer Program.cs konfigurieren. Ausführliche Informationen zum Filtern dieser Protokolle finden Sie unter Verwalten von Protokollebenen im Modell mit isolierten Workern.

Beispiel für Funktionsmigrationen

Beispiel für HTTP-Trigger

Ein HTTP-Trigger für das In-Process-Modell könnte wie im folgenden Beispiel aussehen:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Ein HTTP-Trigger für die migrierte Version könnte wie das folgende Beispiel aussehen:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Aktualisieren Ihrer Funktions-App in Azure

Das Aktualisieren der Funktions-App auf das Workermodell „Isoliert“ umfasst zwei Änderungen, die zusammen abgeschlossen werden sollen, da die App in einen Fehlerzustand wechselt, wenn Sie nur eine ausführen. Beide Änderungen führen auch dazu, dass der App-Prozess neu gestartet wird. Aus diesen Gründen sollten Sie das Update mit einem Stagingslot durchführen. Stagingslots tragen dazu bei, die Ausfallzeiten Ihrer App zu minimieren, und sie ermöglichen Ihnen, Ihren migrierten Code mit Ihrer aktualisierten Konfiguration in Azure zu testen und zu überprüfen. Anschließend können Sie Ihre vollständig migrierte App über einen Austauschvorgang im Produktionsslot bereitstellen.

Wichtig

Wenn die bereitgestellten Nutzdaten einer App nicht mit der konfigurierten Runtime übereinstimmen, wechselt sie in einen Fehlerzustand. Während des Migrationsprozesses versetzen Sie die App in diesen Zustand, aber idealerweise nur vorübergehend. Bereitstellungsslots tragen dazu bei, die Auswirkungen dieses Vorgangs zu minimieren, da der Fehlerzustand in Ihrer Stagingumgebung (Nicht-Produktionsumgebung) behoben wird, bevor die Änderungen als einzelnes Update auf Ihre Produktionsumgebung angewendet werden. Slots werden auch vor Fehlern geschützt und ermöglichen Ihnen, andere Probleme zu erkennen, bevor sie die Produktion erreichen.

Während des Prozesses werden möglicherweise immer noch Fehler in Protokollen angezeigt, die aus Ihrem Stagingslot (Nicht-Produktionsslot) stammen. Sie sind zwar zu erwarten, sollten jedoch nicht mehr auftreten, wenn Sie die Schritte ausgeführt haben. Bevor Sie den Slotwechsel ausführen, sollten Sie sich vergewissern, dass diese Fehler nicht mehr ausgelöst werden und dass Ihre Anwendung erwartungsgemäß funktioniert.

Führen Sie die folgenden Schritte aus, um Bereitstellungsslots zum Aktualisieren der Funktions-App auf das Workermodell „Isoliert“ zu verwenden:

  1. Erstellen Sie einen Bereitstellungsslot, falls noch keiner vorhanden ist. Möglicherweise sollten Sie sich auch mit dem Austauschprozess des Slots vertraut machen und sicherstellen, dass Sie Aktualisierungen an der vorhandenen Anwendung mit minimalen Unterbrechungen vornehmen können.

  2. Ändern Sie die Konfiguration des Stagingslots (nicht des Produktionsslots), um das Workermodell „Isoliert“ zu verwenden, indem Sie die Anwendungseinstellung FUNCTIONS_WORKER_RUNTIME auf dotnet-isolated festlegen. FUNCTIONS_WORKER_RUNTIME sollte nicht als Sloteinstellung gekennzeichnet werden.

    Wenn Sie im Rahmen Ihres Updates außerdem auf eine andere Version von .NET abzielen, sollten Sie auch die Stapelkonfiguration ändern. Informationen hierzu finden Sie unter Aktualisieren der Stapelkonfiguration. Sie können dieselben Anweisungen auch für zukünftige .NET-Versionsupdates verwenden.

    Wenn Sie eine automatisierte Infrastrukturbereitstellung wie eine CI/CD-Pipeline nutzen, stellen Sie sicher, dass die Automatisierungen ebenfalls aktualisiert werden, damit FUNCTIONS_WORKER_RUNTIME weiter auf dotnet-isolated festgelegt bleibt und die richtige .NET-Version als Ziel verwendet wird.

  3. Veröffentlichen Sie Ihr migriertes Projekt im Stagingslot (nicht im Produktionsslot) Ihrer Funktions-App.

    Wenn Sie Visual Studio verwenden, um ein Projekt mit dem Workermodell „Isoliert“ in einer vorhandenen App oder einem vorhandenen Slot zu veröffentlichen, die bzw. der das In-Process-Modell verwendet, kann der vorherige Schritt auch gleichzeitig für Sie ausgeführt werden. Wenn Sie den vorherigen Schritt noch nicht abgeschlossen haben, fordert Visual Studio Sie auf, die Funktions-App während der Bereitstellung zu aktualisieren. Visual Studio stellt dies als einen Vorgang dar, obwohl es weiterhin zwei separate Vorgänge sind. Möglicherweise werden während des Übergangs weiterhin Fehler in Ihren Protokollen aus dem Stagingslot (Nicht-Produktionsslot) angezeigt.

  4. Vergewissern Sie sich, dass Ihre Anwendung im Stagingslot (nicht Produktionsslot) wie erwartet funktioniert.

  5. Führen Sie einen Slotwechsel aus, um die Änderungen, die Sie am Stagingslot (nicht am Produktionsslot) vorgenommen haben, auf den Produktionsslot anzuwenden. Ein Slotwechsel erfolgt als einzelnes Update. Dadurch wird verhindert, dass der zwischenzeitliche Fehlerzustand auch in Ihrer Produktionsumgebung auftritt.

  6. Vergewissern Sie sich, dass Ihre Anwendung im Produktionsslot wie erwartet funktioniert.

Nachdem Sie diese Schritte ausgeführt haben, ist die Migration abgeschlossen, und Ihre App wird im Workermodell „Isoliert“ ausgeführt. Glückwunsch! Wiederholen Sie die Schritte aus diesem Leitfaden bei Bedarf für weitere Apps, die migriert werden müssen.

Nächster Schritt

Weitere Informationen zum isolierten Workermodell

  • Last updated on