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

Dieser Artikel führt Sie durch den Prozess der sicheren Migration Ihrer .NET-Funktions-App aus dem In-Process-Modell zum isolierten Workermodell. 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, nutze die folgenden Anleitungen, um deine Host-Version zu aktualisieren. Diese Leitfäden zur Migration der Hostversion unterstützen Sie auch bei der Migration zum Workermodell „Isoliert“.

• Migration von Apps von Azure Functions Version 2.x und 3.x zu Version 4.x
• Apps aus Azure Functions Version 1.x auf Version 4.x migrieren

Wenn dieser Artikel unterstützt wird, nutzt dieser Artikel ASP.NET Core Integration im isolierten Arbeitsmodell, wodurch die Leistung verbessert wird und ein vertrautes Programmiermodell bereitgestellt wird, 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 generieren, die derzeit das In-Process-Modell verwenden.

Das Skript verwendet das Abonnement, das Azure PowerShell aktuell zur Verwendung konfiguriert hat. Du kannst das Abonnement ändern, indem du zuerst Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' ausführst und <YOUR SUBSCRIPTION ID> durch die ID des Abonnements ersetzt, das du bewerten möchtest.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Wählen Sie Ihre Ziel-.NET-Version aus.

Wenn Sie auf das isolierte Worker-Modell migrieren, wählen Sie Ihr Ziel basierend darauf, ob Ihre Funktions-App und ihre Abhängigkeiten auf .NET (früher .NET Core) laufen können:

• Wenn deine App und ihre Abhängigkeiten auf .NET laufen können, ziele auf .NET 10.
• Wenn Ihre App auf Bibliotheken oder APIs angewiesen ist, die nur im .NET Framework verfügbar sind, wählen Sie .NET Framework 4.8.

Vorbereiten der Migration

Bevor Sie eine App auf das isolierte Worker-Modell migrieren, lesen Sie den Inhalt dieses Leitfadens gründlich durch. Mach dich außerdem mit den Eigenschaften des Isolated Worker-Modells und den Unterschieden zwischen den beiden Modellen vertraut.

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 vollständig lokal, indem Sie Version 4.x der Azure Functions Core Tools verwenden.
3. Aktualisieren Sie Ihre Funktions-App in Azure auf das isolierte Modell.

Migrieren Ihres lokalen Projekts

Dieser Abschnitt beschreibt die verschiedenen Änderungen, die Sie an Ihrem lokalen Projekt vornehmen müssen, um es auf das Isolated Worker-Modell umzustellen. Einige der Schritte ändern sich basierend auf Ihrer Zielversion von .NET. Verwenden Sie die Registerkarten zur Auswahl der Anweisungen, die Ihrer gewünschten Version entsprechen.

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 zeigt eine .csproj-Projektdatei, die .NET 8 auf 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:

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
    <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>

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <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>
    <Folder Include="Properties\" />
  </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

Wenn Sie auf das isolierte Worker-Modell migrieren, ändern Sie die Pakete, auf die Ihre Anwendung verweist.

Falls du es noch nicht getan hast, aktualisiere dein Projekt auf die neuesten stabilen Versionen von:

• Microsoft.Azure. Functions.Worker
• Azure.Functions.Sdk als Projekt-SDK

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:

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.

Ihre isolierte Workermodellanwendung sollte nicht auf Pakete in den namespaces Microsoft.Azure.WebJobs.* oder Microsoft.Azure.Functions.Extensions verweisen. Wenn noch Verweise auf diese vorhanden sind, sollten Sie sie entfernen.

Datei „program.cs“

Wenn Sie in einen isolierten Worker-Prozess migrieren, fügen Sie Ihrem Projekt eine Program.cs-Datei mit folgendem Inhalt hinzu:

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();

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

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

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

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 richten Application Insights mithilfe des Application Insights SDK ein. Für die OpenTelemetry-basierte Application Insights-Konfiguration, die im Leitfaden für das isolierte Worker-Modell beschrieben wird, siehe 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 eine Trigger- und Bindungskonfiguration, die über die Anwendungseinstellungen, Key Vault-Referenzen oder App-Konfigurationsreferenzen bereitgestellt werden sollte.

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 dieser Änderungen beziehen sich auf die Attribute, Parameter und Rückgabetypen, aus denen die Funktionssignatur besteht. Für jede Ihrer Funktionen nehmen Sie Änderungen vor:

• 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 einen Saitenaustausch über Ihr Projekt hinweg 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. Verwenden Sie eine Abhängigkeitsinjektion, um eine 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(...)]. Die Bindung benötigt die Eigenschaft Access nicht mehr, sodass du diesen Parameter entfernen kannst. [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] wird also [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Ausgabebindungen aus der Funktionsparameterliste verschieben. Wenn du nur eine Ausgabebindung hast, kannst du diese Bindung 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. Für Ausgabebindungen gilt: Wenn die In-Process-Modellversion ein IAsyncCollector<T>verwendet hat, kann man diesen Typ ersetzen, indem man an ein Array des Zieltyps bindet: 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.

Migration zur asynchronen HTTP-Stream-I/O

Wenn eine HTTP-ausgelöste Funktion eine ASP.NET Core-Integration verwendet, ersetzen Sie synchrone Lese- und Schreibvorgänge in HTTP-Anfrage- und Antwortströme durch asynchrone Methoden. Synchrone Operationen können mit InvalidOperationException: Synchronous operations are disallowedversagen. Zum Beispiel ersetzen ReadToEnd wir durch ReadToEndAsync, Write durch WriteAsync, WriteString durch WriteStringAsync, und Flush durch FlushAsync.

Wenn Sie auf diese Operationen warten, markieren Sie die Funktion bzw. Methode als async und schließen Sie ihren Rückgabetyp in Task<T> ein. Ändern Sie zum Beispiel IActionResult in Task<IActionResult> oder MultiResponse in Task<MultiResponse>. ASP.NET Core erlaubt standardmäßig keine synchrone Anfrage- und Antwort-I/O, da synchrone I/O zu Threadpool-Mangel führen kann. Wenn eine Abhängigkeit oder Serializer keine asynchrone I/O unterstützt, siehe JSON-Serialisierung mit ASP.NET Core-Integration für Anweisungen zur Ermöglichung synchroner I/O (AllowSynchronousIO) als Kompatibilitätsoption.

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. Stellen Sie sicher, dass Ihre local.settings.json-Datei mindestens folgende 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 sich Ihre Application Insights-Konfiguration jedoch in dieser Datei aus Ihrem Prozessmodellprojekt befindet, sollten Sie in Ihrer Program.cs Datei weitere Änderungen vornehmen. Die host.json-Datei steuert nur das Logging ab der Laufzeit des Functions-Hosts. Im Isolated Worker-Modell stammen einige dieser Logs direkt aus deiner Anwendung, was dir mehr Kontrolle gibt. 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 Customizing JSON serialization.

Da das In-Process-Modell Newtonsoft.Json verwendete, überprüfe auch die Serialisierungsattribute bei allen Typen, an die deine Funktionen gebunden sind. System.Text.Json ignoriert Attribute wie [JsonProperty] und [JsonIgnore] von Newtonsoft.Json. Es bindet die betroffene Eigenschaft an ihren Standardwert, ohne einen Fehler zu melden. Entweder ersetzen Sie sie durch ihre System.Text.Json-Äquivalente , wie [JsonPropertyName], oder konfigurieren Sie Newtonsoft.Json für die Schicht, die die Nutzlast verarbeitet.

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 HTTP-Trigger-Migration

Das folgende Beispiel vergleicht eine HTTP-ausgelöste Funktion vor und nach der Migration mit dem isolierten Worker-Modell.

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(ILogger<HttpTriggerCSharp> 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"]}!");
        }
    }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
    {
        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Aktualisieren Sie Ihre Funktions-App in Azure

Nachdem du dein lokales Projekt migriert hast, aktualisiere deine Funktions-App-Konfiguration und deploye den migrierten Code, um den Wechsel zum isolierten Worker-Modell abzuschließen.

Bevor Sie Ihr migriertes Projekt veröffentlichen

Bevor Sie Ihr aktualisiertes Codeprojekt veröffentlichen, planen Sie, diese beiden Änderungen gemeinsam durchzuführen:

• Ändere die FUNCTIONS_WORKER_RUNTIME Anwendungseinstellung auf dotnet-isolated.
• Veröffentlichen Sie das migrierte Isolated-Worker-Projekt in Ihrer Funktions-App.

Jede Änderung startet die App neu. Nachdem du die erste Änderung abgeschlossen hast, stimmen der bereitgestellte Code und die konfigurierte Laufzeit nicht mehr überein, was zu einem Runtime/Payload-Mismatch-Fehler (AZFD0013) führt, bis du die zweite Änderung abgeschlossen hast.

Wenn möglich, nutzen Sie während der Migration einen Staging-Slot . Ein Staging Slot bietet Ihnen folgende Vorteile:

• Hält den temporären Fehlerzustand, der durch Code- und Laufzeit-Mismatch entsteht, aus der Produktion heraus.
• Damit kannst du den migrierten Code und die Konfiguration testen, bevor du sie in die Produktion einstellst.

Du könntest in den Protokollen des Staging-Slots Fehler sehen, während du die beiden Änderungen vornimmst. Bevor du den Slot tauschst, solltest du bestätigen, dass die Fehler aufgehört haben und die App wie erwartet funktioniert.

Aktualisieren Sie Ihre Funktions-App mithilfe von Slots

Verwenden Sie die folgenden Schritte, um Ihre Function App mithilfe eines Staging-Slots auf das isolierte Workermodell umzustellen:

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. Kennzeichne FUNCTIONS_WORKER_RUNTIME nicht als Slot-Einstellung.

   Wenn du im Rahmen deines Updates auch eine andere Version von .NET anvisierst, ändere die Stack-Konfiguration. Informationen hierzu finden Sie unter Aktualisieren der Stapelkonfiguration. Sie können die gleichen Anweisungen für zukünftige .NET Versionsupdates verwenden, die Sie vornehmen.

   Wenn Sie über eine automatisierte Infrastrukturbereitstellung wie etwa eine CI/CD-Pipeline verfügen, stellen Sie sicher, dass auch die Automatisierungen aktualisiert werden, damit dotnet-isolated weiterhin auf FUNCTIONS_WORKER_RUNTIME festgelegt ist 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 isolierten Arbeitsmodellen in einer vorhandenen App oder einem vorhandenen Steckplatz zu veröffentlichen, die das In-Process-Modell verwendet, kann es auch den vorherigen Schritt für Sie gleichzeitig ausführen. Wenn Sie den vorherigen Schritt nicht abgeschlossen haben, fordert Visual Studio Sie auf, die Funktions-App während der Bereitstellung zu aktualisieren. Visual Studio präsentiert dieses Update als eine einzelne Operation, aber diese Updates sind immer noch zwei separate Operationen. 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