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 isolierten Workermodell.

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,3
.NET 82 LTS Isoliertes Workermodell
.NET 7 STS (Ende des Supports 14. Mai 2024) Isoliertes Workermodell
.NET 6 LTS (Ende des Supports am 12. November 2024) Isoliertes Workermodell,
In-Process-Modell3
.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. 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 .NET 8 wird für das In-Process-Modell noch nicht unterstützt, obwohl es im isolierten Workermodell verfügbar ist. Informationen zu .NET 8-Plänen, einschließlich zukünftiger Optionen für das In-Process-Modell, finden Sie im Beitrag mit dem Update zur Azure Functions-Roadmap.

3 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.

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.

In diesem Handbuch werden keine spezifischen Beispiele für .NET 7 oder .NET 6 vorgestellt. 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 isolierten Workermodell migrieren, sollten Sie sich sorgfältig mit dem Inhalt dieses Leitfadens sowie mit den Features des isolierten Workermodells 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 isolierten Workermodell 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>

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

Der Rest dieses Abschnitts führt Sie durch die einzelnen Schritte.

Funktionsattribute

Das FunctionName-Attribut wird durch das Function-Attribut im isolierten Workermodell 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 einen zusätzlichen ILogger-Parameter zu Ihrer Funktion hinzufügen, oder Sie können die Abhängigkeitsinjektion verwenden, um eine ILogger<T> zu erhalten. Wenn Sie bereits Abhängigkeitsinjektion verwendet haben, funktionieren dieselben Mechanismen im isolierten Arbeitsmodell.

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 Codeausschnitt durch den Namen der 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 Prozessmodell verwendet haben, wäre dies jetzt CosmosDBInput.
    • Ausgabebindungen benötigen in der Regel „Output“, der ihrem Namen hinzugefügt wird. Wenn Sie z. B. das Queue-Ausgabebindungsattribut im Prozessmodell verwendet haben, wäre dies 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, den Sie für „AzureWebJobsStorage“ konfiguriert haben, 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 kann wie im folgenden 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 Upgrade Ihrer Funktions-App auf das isolierte Modell umfasst zwei Schritte:

  1. Ändern Sie die Konfiguration der Funktions-App zur Verwendung des isolierten Modells, indem Sie die Anwendungseinstellung FUNCTIONS_WORKER_RUNTIME auf dotnet-isolated festlegen. Stellen Sie sicher, dass eine etwaige Bereitstellungsautomatisierung in gleicher Weise aktualisiert wird.
  2. Veröffentlichen Sie Ihr migriertes Projekt in der aktualisierten Funktions-App.

Wenn Sie Visual Studio zum Veröffentlichen eines Projekts mit isoliertem Workermodell für eine vorhandene App verwenden, die das In-Process-Model verwendet, werden Sie aufgefordert, Visual Studio die App während der Bereitstellung aktualisieren zu lassen. Dadurch werden beide Schritte gleichzeitig ausgeführt.

Wenn Sie die Downtime minimieren müssen, sollten Sie einen Stagingslot verwenden, um 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.

Sobald Sie diese Schritte durchgeführt haben, wurde Ihre App vollständig zum isolierten Modell migriert. 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