Teilen über

Migrieren von .NET-Apps vom In-Process-Modell zum isolierten Workermodell

  • Artikel

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. Ist dies nicht der Fall, sollten Sie stattdessen die Anleitungen zum Upgrade Ihrer Hostversion befolgen:

Diese Leitfäden zur Migration der Hostversion unterstützen Sie auch bei der Migration zum Workermodell „Isoliert“.

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 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 9 Vorschauversion3 Isoliertes Workermodell
.NET 8 LTS (Ende des Supports am 10. November 2026) Isoliertes Workermodell,
In-Process-Modell2
.NET 6 LTS (Ende des Supports am 12. November 2024) Isoliertes Workermodell,
In-Process-Modell2
.NET Framework 4.8 Siehe Richtlinie 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 Ausführliche Informationen zu Support, aktuellen Einschränkungen und Anweisungen zur Verwendung der Vorschauversion finden Sie unter .NET-Vorschauversionen im isolierten Workermodell.

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 9 (Vorschauversion) oder .NET 6. Wenn Sie diese Versionen als Ziel verwenden müssen, können Sie die .NET 8-Beispiele anpassen.

Vorbereiten der Migration

Sofern noch nicht geschehen, ermitteln Sie mithilfe von Azure PowerShell die Liste der Apps, die in Ihrem aktuellen Azure-Abonnement migriert werden müssen.

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.

Gehen Sie zum Migrieren der Anwendung wie folgt vor:

  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 vollständig lokal 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. Für diese Schritte wird ein lokales C#-Projekt vorausgesetzt. Wenn Ihre App stattdessen ein C#-Skript (.csx-Dateien) verwendet, sollten Sie zum Projektmodell wechseln, bevor Sie fortfahren.

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. Wie Sie tun, 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 6 in Version 4.x verwendet:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.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 eines der folgenden Verfahren, um diese XML-Datei für die Ausführung im isolierten Workermodell zu aktualisieren:

Für diese Schritte wird ein lokales C#-Projekt vorausgesetzt. Wenn Ihre App stattdessen ein C#-Skript (.csx-Dateien) verwendet, sollten Sie zum Projektmodell wechseln, bevor Sie fortfahren.

Folgende Ä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 dem 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. Sie ersetzen diese Pakete in einem späteren Schritt.

  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 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 Build-Schritten oder einer CI/CD-Pipeline, existieren könnten.

Paketverweise

Bei der Migration auf das isolierte 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 Ersetzen von
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 eine Program.cs-Datei 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 von ConfigureFunctionsWebApplication durch einen Aufruf von ConfigureFunctionsWorkerDefaults ersetzen. 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 Program.cs-Datei ersetzt jede Datei, die das FunctionsStartup-Attribut aufweist, was in der Regel eine Startup.cs-Datei ist. An Stellen, an denen Ihr FunctionsStartup-Code IFunctionsHostBuilder.Services referenzieren würde, können Sie stattdessen Anweisungen innerhalb der .ConfigureServices()-Methode der HostBuilder in Ihrem Program.cs hinzufügen. Weitere Informationen zum Arbeiten mit Program.cs finden Sie unter Start und Konfiguration im Handbuch für isolierte Arbeitsmodelle.

Die oben genannten Standardbeispiele für Program.cs umfassen das Einrichten der Application Insights-Integration für das Modell mit isolierten Workern. Sie müssen in Ihrer Datei Program.cs auch alle Protokollfilter konfigurieren, die auf Protokolle angewandt werden sollen, die aus Code in Ihrem Projekt stammen. Im Modell mit isolierten Workern steuert die Datei host.json nur Ereignisse, die von der Functions-Hostruntime 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.

Sie können zwar benutzerdefinierte Konfigurationsquellen als Teil von HostBuilder registrieren, sollten dabei aber beachten, dass diese ebenfalls nur für Code in Ihrem Projekt gelten. Eine Trigger- und Bindungskonfiguration wird ebenfalls für die Plattform benötigt. Sie wird über die Anwendungseinstellungen, Key Vault-Verweise oder App Configuration-Verweisfeatures bereitgestellt.

Nachdem Sie alles aus einer vorhandenen FunctionsStartup- zu einer Program.cs-Datei verschoben haben, können Sie das FunctionsStartup-Attribut und die Klasse löschen, auf die es 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.

Logging

Im In-Process-Modell können Sie Ihrer Funktion einen zusätzlichen ILogger-Parameter hinzufügen, oder Sie können die Abhängigkeitsinjektion verwenden, um eine ILogger<T> abzurufen. Wenn Sie bereits die Abhängigkeitsinjektion verwendet haben, 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.

Auslösen und Bindung von Ä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 werden:

  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.
    • Eingabebindungen benötigen in der Regel „Input“, der ihrem Namen hinzugefügt wird. Wenn Sie z. B. das CosmosDB-Eingabebindungsattribut im In-Process-Modell verwendet haben, wäre das Attribut jetzt CosmosDBInput.
    • Ausgabebindungen benötigen in der Regel „Output“, der ihrem Namen hinzugefügt wird. 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 isolierte Workermodellversion 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 abweichen. Sie müssen den Wert nicht im Rahmen der Migration ändern.

Datei „host.json“

In Ihrer Datei host.json sind keine Änderungen erforderlich. Wenn Ihre Application Insights-Konfiguration in dieser Datei jedoch von Ihrem Projekt mit In-Process-Modell stammt, sollten Sie zusätzliche Änderungen an Ihrer 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 nicht bei allen Anwendungen benötigt, vielmehr müssen Sie selbst einschätzen, ob sie für Ihre Szenarien relevant sind.

JSON-Serialisierung

Standardmäßig wird im Modell mit isolierten Workern für die JSON-Serialisierung System.Text.Json verwendet. Informationen zum Anpassen von Serialisierungsoptionen oder zum Umstellen auf JSON.NET (Newtonsoft.Json) finden Sie in diesen Anweisungen.

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. In der Datei host.json können Sie Regeln für die Hostprotokollierung konfigurieren, aber um Protokolle über Ihren Code zu steuern, müssen Sie Filterregeln in Ihre Datei Program.cs einfügen. 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 angewandt 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 Ihrem 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. Lesen Sie dazu die Anweisungen zum Aktualisieren der Stapelkonfiguration für das Workermodell „Isoliert“. Sie verwenden dieselben Anweisungen auch für zukünftige .NET-Versionsupdates.

    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 das In-Process-Modell verwenden, wird der vorherige Schritt gleichzeitig ausgeführt. 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 durch. Dadurch werden Änderungen, die Sie in Ihrem Stagingslot (nicht im Produktionsslot) vorgenommen haben, auf den Produktionsslot angewandt. 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. Herzlichen Glückwunsch! Wiederholen Sie die Schritte aus diesem Leitfaden bei Bedarf für weitere Apps, die migriert werden müssen.

Nächste Schritte

Weitere Informationen zum isolierten Workermodell