Delen via

C#-apps migreren van het in-procesmodel naar het geïsoleerde werkrolmodel

Belangrijk

De ondersteuning voor het in-process model eindigt op 10 november 2026. We raden u ten zeerste aan uw apps te migreren naar het geïsoleerde werkrolmodel door de instructies in dit artikel te volgen.

In dit artikel wordt u begeleid bij het proces voor het veilig migreren van uw .NET-functie-app van het in-procesmodel naar het geïsoleerde werkrolmodel. Zie de vergelijking van de uitvoeringsmodus voor meer informatie over de verschillen op hoog niveau tussen deze modellen.

In deze handleiding wordt ervan uitgegaan dat uw app wordt uitgevoerd op versie 4.x van de Functions-runtime. Als dat niet het geval is, moet u de volgende handleidingen gebruiken om uw hostversie te upgraden. Deze migratiehandleidingen voor host-versieversies helpen u ook bij het migreren naar het geïsoleerde werkermodel terwijl u ze doorloopt.

Wanneer dit wordt ondersteund, maakt dit artikel gebruik van ASP.NET Core-integratie in het geïsoleerde werkrolmodel, wat de prestaties verbetert en een vertrouwd programmeermodel biedt wanneer uw app HTTP-triggers gebruikt.

Functie-apps identificeren die moeten worden gemigreerd

Gebruik het volgende Azure PowerShell-script om een lijst met functie-apps te genereren in uw abonnement die momenteel gebruikmaken van het in-process model.

Het script maakt gebruik van het abonnement dat Momenteel is geconfigureerd voor gebruik met Azure PowerShell. U kunt het abonnement wijzigen door eerst uit te voeren Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' en te vervangen door <YOUR SUBSCRIPTION ID> de id van het abonnement dat u wilt evalueren.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Kies uw .NET-doelversie

Op versie 4.x van de Functions-runtime is uw .NET-functie-app gericht op .NET 6 of .NET 8 wanneer u het in-procesmodel gebruikt.

Wanneer u uw functie-app migreert, hebt u de mogelijkheid om de doelversie van .NET te kiezen. U kunt uw C#-project bijwerken naar een van de volgende versies van .NET die worden ondersteund door Functions versie 4.x:

.NET-versie Releasetype voor .NET Official Support Policy Functions-procesmodel1,2
.NET 9 STS (einde van ondersteuning 12 mei 2026) Geïsoleerde werkermodel
.NET 8 LTS (einde van ondersteuning 10 november 2026) Model voor geïsoleerde werker
In-process model2
.NET Framework 4.8 Beleid weergeven Geïsoleerd werknemermodel

1 Het geïsoleerde werkrolmodel ondersteunt LTS-versies (Long Term Support) en STS-versies (Standard Term Support) van .NET, evenals .NET Framework. Het in-process model ondersteunt alleen LTS-releases van .NET, eindigend op .NET 8. Zie Verschillen tussen proces- en isoleerproces .NET Azure Functions voor een volledige functie en functionaliteitsvergelijking tussen de twee modellen.

2 Ondersteuning eindigt op het procesmodel op 10 november 2026. Zie deze ondersteuningsaankondiging voor meer informatie. Voor voortdurende volledige ondersteuning dient u uw apps te migreren naar het geïsoleerde werkermodel.

Tip

U wordt aangeraden een upgrade uit te voeren naar .NET 8 op het geïsoleerde werkrolmodel. Dit biedt een snel migratiepad naar de volledig uitgebrachte versie met het langste ondersteuningsvenster van .NET.

Deze handleiding bevat geen specifieke voorbeelden voor .NET 9. Als u deze versie wilt toepassen, kunt u de .NET 8-voorbeelden aanpassen.

Voorbereiden op migratie

Voordat u een app migreert naar het geïsoleerde werkrolmodel, moet u de inhoud van deze handleiding grondig bekijken. U moet ook vertrouwd raken met de functies van het geïsoleerde werkrolmodel en de verschillen tussen de twee modellen.

De toepassing migreren:

  1. Migreer uw lokale project naar het geïsoleerde werkermodel door de stappen in Uw lokale project migreren te volgen.
  2. Nadat u uw project hebt gemigreerd, test u de app volledig lokaal met versie 4.x van de Azure Functions Core Tools.
  3. Werk uw functie-app in Azure bij naar het geïsoleerde model.

Uw lokale project migreren

De sectie bevat een overzicht van de verschillende wijzigingen die u moet aanbrengen in uw lokale project om het naar het geïsoleerde werkrolmodel te verplaatsen. Sommige van de stappen worden gewijzigd op basis van uw doelversie van .NET. Gebruik de tabbladen om de instructies te selecteren die overeenkomen met de gewenste versie.

Tip

Als u overstapt op een LTS- of STS-versie van .NET, kan de .NET-upgradeassistent worden gebruikt om automatisch veel van de wijzigingen aan te brengen die worden vermeld in de volgende secties.

Converteer eerst het projectbestand en werk uw afhankelijkheden bij. Terwijl u bezig bent, ziet u bouwerfouten voor het project. In de volgende stappen gaat u de bijbehorende wijzigingen aanbrengen om deze fouten te verwijderen.

Projectbestand

Het volgende voorbeeld is een .csproj-projectbestand dat gebruikmaakt van .NET 8 op versie 4.x:

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

Gebruik een van de volgende procedures om dit XML-bestand bij te werken voor uitvoering in het geïsoleerde werkrolmodel:

Bij deze stappen wordt uitgegaan van een lokaal C#-project; als uw app in plaats daarvan C#-script (.csx-bestanden ) gebruikt, moet u converteren naar het projectmodel voordat u doorgaat.

De volgende wijzigingen zijn vereist in het XML-projectbestand .csproj :

  1. Stel de waarde van PropertyGroup. TargetFramework aan net8.0.

  2. Stel de waarde van PropertyGroup. AzureFunctionsVersion aan v4.

  3. Voeg het volgende OutputType-element toe aan de PropertyGroup.

    <OutputType>Exe</OutputType>

  4. In de ItemGroup. PackageReference lijst, vervang de pakketverwijzing naar Microsoft.NET.Sdk.Functions door de volgende verwijzingen:

      <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" />

    Noteer eventuele verwijzingen naar andere pakketten in de Microsoft.Azure.WebJobs.* naamruimten. U vervangt deze pakketten in een latere stap.

  5. Voeg de volgende nieuwe ItemGrouptoe:

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

Nadat u deze wijzigingen hebt aangebracht, ziet het bijgewerkte project eruit als in het volgende voorbeeld:

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

Het wijzigen van het doelframework van uw project vereist mogelijk ook wijzigingen in onderdelen van uw hulpprogrammaketen, buiten projectcode. In VS Code moet u bijvoorbeeld mogelijk de azureFunctions.deploySubpath extensie-instelling bijwerken via gebruikersinstellingen of het bestand .vscode/settings.json van uw project. Controleer of er afhankelijkheden zijn van de frameworkversie die mogelijk buiten uw projectcode bestaat, als onderdeel van de buildstappen of een CI/CD-pijplijn.

Pakketverwijzingen

Wanneer u migreert naar het geïsoleerde werkrolmodel, moet u de pakketten wijzigen waarnaar uw toepassing verwijst.

Als u dat nog niet hebt gedaan, werkt u uw project bij om te verwijzen naar de nieuwste stabiele versies van:

Afhankelijk van de triggers en bindingen die uw app gebruikt, moet uw app mogelijk verwijzen naar een andere set pakketten. In de volgende tabel ziet u de vervangingen voor enkele van de meest gebruikte extensies:

Scenario Wijzigingen in pakketverwijzingen
Timertrigger Toevoegen
Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage-bindingen Vervangen
Microsoft.Azure.WebJobs.Extensions.Storage
wordt uitgevoerd met
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues en
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blob-bindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Wachtrijkoppelingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabelbindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.Tables
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.CosmosDB
en/of
Microsoft.Azure.WebJobs.Extensions.DocumentDB
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.ServiceBus
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.EventHubs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Bindingen voor Event Grid Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.EventGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-bindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.SignalRService
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.DurableTask
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Duurzame Functies
(SQL opslagprovider)		 Verwijzingen vervangen naar
Microsoft.DurableTask.SqlServer.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Duurzame Functies
(Netherite-opslagprovider)		 Vervang verwijzingen door
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.SendGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-bindingen Vervang verwijzingen door
Microsoft.Azure.WebJobs.Extensions.Kafka
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ bindingen Vervang verwijzingen naar
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Afhankelijkheidsinjectie
en opstartconfiguratie		 Verwijzingen verwijderen naar
Microsoft.Azure.Functions.Extensions
(Het geïsoleerde werkrolmodel biedt deze functionaliteit standaard.)

Zie Ondersteunde bindingen voor een volledige lijst met extensies die u kunt overwegen en raadpleeg de documentatie van elke extensie voor volledige installatie-instructies voor het geïsoleerde procesmodel. Zorg ervoor dat u de nieuwste stabiele versie installeert van alle pakketten die u wilt gebruiken.

Tip

Voor eventuele wijzigingen in extensieversies tijdens dit proces moet u het host.json bestand mogelijk ook bijwerken. Lees de documentatie van elke extensie die u gebruikt. De Service Bus-extensie heeft bijvoorbeeld belangrijke wijzigingen in de structuur tussen versie 4.x en 5.x. Zie Azure Service Bus-bindingen voor Azure Functions voor meer informatie.

Uw geïsoleerde werkrolmodeltoepassing mag niet verwijzen naar pakketten in de Microsoft.Azure.WebJobs.* naamruimten of Microsoft.Azure.Functions.Extensions. Als u nog verwijzingen naar deze referenties hebt, moeten ze worden verwijderd.

Tip

Uw app kan ook afhankelijk zijn van Azure SDK-typen, hetzij als onderdeel van uw triggers en bindingen of als zelfstandige afhankelijkheid. U zou deze gelegenheid moeten aangrijpen om deze ook bij te werken. De nieuwste versies van de Functions-extensies werken met de nieuwste versies van de Azure SDK voor .NET, bijna alle pakketten waarvoor het formulier Azure.*is.

Program.cs-bestand

Wanneer u migreert om uit te voeren in een geïsoleerd werkproces, moet u een Program.cs bestand toevoegen aan uw project met de volgende inhoud:

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

Dit voorbeeld omvat ASP.NET Core-integratie om de prestaties te verbeteren en een vertrouwd programmeermodel te bieden wanneer uw app HTTP-triggers gebruikt. Als u geen HTTP-triggers wilt gebruiken, kunt u de aanroep ConfigureFunctionsWebApplication vervangen door een aanroep naar ConfigureFunctionsWorkerDefaults. Als u dit doet, kunt u de verwijzing Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore uit het projectbestand verwijderen. Voor de beste prestaties, zelfs voor functies met andere triggertypen, moet u echter de FrameworkReference bij ASP.NET Core houden.

Het bestand Program.cs vervangt elk bestand dat het FunctionsStartup kenmerk heeft. Dit is meestal een Startup.cs bestand. Op plaatsen waar uw FunctionsStartup code IFunctionsHostBuilder.Services zou verwijzen, kun je in plaats daarvan instructies toevoegen in de .ConfigureServices() methode van de HostBuilder in je Program.cs. Zie de handleiding voor het opstarten en configureren van het geïsoleerde werkmodel voor meer informatie over het werken met Program.cs.

De standaard Program.cs voorbeelden die eerder zijn beschreven, omvatten de installatie van Application Insights. In uw Program.cs moet u ook logboekfilters configureren die van toepassing moeten zijn op logboeken die afkomstig zijn van code in uw project. In het geïsoleerde werkrolmodel beheert het host.json bestand alleen gebeurtenissen die worden verzonden door de Functions-hostruntime. Als u geen filterregels configureert in Program.cs, ziet u mogelijk verschillen in de logboekniveaus die aanwezig zijn voor verschillende categorieën in uw telemetrie.

Hoewel u aangepaste configuratiebronnen kunt registreren als onderdeel van de HostBuilderconfiguratie, zijn deze ook alleen van toepassing op code in uw project. Het platform heeft ook trigger- en bindingsconfiguratie nodig. Dit moet worden opgegeven via de functies voor toepassingsinstellingen, Key Vault-verwijzingen of App Configuration-verwijzingen .

Nadat u alles van een bestaand FunctionsStartup naar het Program.cs-bestand hebt verplaatst, kunt u het FunctionsStartup kenmerk en de klasse waarop het is toegepast, verwijderen.

Wijzigingen in functiehandtekening

Sommige sleuteltypen veranderen tussen het in-procesmodel en het geïsoleerde werkrolmodel. Veel van deze hebben betrekking op de kenmerken, parameters en retourtypen waaruit de functiehandtekening bestaat. Voor elk van uw functies moet u het volgende wijzigen:

  • Het functiekenmerk, waarmee ook de naam van de functie wordt ingesteld
  • Hoe de functie een ILogger/ILogger<T> verkrijgt
  • Trigger- en bindingseigenschappen en -parameters

In de rest van deze sectie wordt u begeleid bij elk van deze stappen.

Functiekenmerken

Het Function kenmerk in het geïsoleerde werkrolmodel vervangt het FunctionName kenmerk. Het nieuwe kenmerk heeft dezelfde handtekening en het enige verschil is in de naam. U kunt daarom gewoon een tekenreeksvervanging uitvoeren in uw project.

Logboekregistratie

In het procesmodel kunt u een optionele ILogger parameter voor uw functie opnemen, of u kunt afhankelijkheidsinjectie gebruiken om een ILogger<T>. Als uw app al afhankelijkheidsinjectie heeft gebruikt, werken dezelfde mechanismen in het geïsoleerde werkrolmodel.

Voor functies die afhankelijk zijn van de ILogger methodeparameter, moet u echter een wijziging aanbrengen. We raden aan om afhankelijkheidsinjectie te gebruiken om een ILogger<T> te verkrijgen. Gebruik de volgende stappen om het logboekregistratiemechanisme van de functie te migreren:

  1. Voeg in uw functieklasse een private readonly ILogger<MyFunction> _logger; eigenschap toe en vervang deze MyFunction door de naam van uw functieklasse.

  2. Maak een constructor voor uw functieklasse die de ILogger<T> parameter als parameter inneemt:

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

    Vervang beide exemplaren van MyFunction het voorgaande codefragment door de naam van uw functieklasse.

  3. Voor logboekregistratiebewerkingen in uw functiecode vervangt u verwijzingen naar de ILogger parameter door _logger.

  4. Verwijder de parameter uit de ILogger functiehandtekening.

Voor meer informatie, zie Loggen in het geïsoleerde werkermodel.

Wijzigingen in triggers en bindingen

Wanneer u de pakketverwijzingen in een vorige stap hebt gewijzigd, hebt u fouten geïntroduceerd voor uw triggers en bindingen die u nu kunt oplossen:

  1. Verwijder eventuele using Microsoft.Azure.WebJobs; verklaringen.

  2. Voeg een using Microsoft.Azure.Functions.Worker; instructie toe.

  3. Wijzig voor elk bindingskenmerk de naam van het kenmerk zoals opgegeven in de referentiedocumentatie, die u kunt vinden in de index Ondersteunde bindingen . Over het algemeen worden de kenmerknamen als volgt gewijzigd:

    • Triggers blijven doorgaans op dezelfde manier genoemd. Is bijvoorbeeld QueueTrigger de kenmerknaam voor beide modellen.
    • Aan de naam van invoerbindingen moet doorgaans Input worden toegevoegd. Als u bijvoorbeeld het CosmosDB kenmerk invoerbinding in het procesmodel hebt gebruikt, zou het kenmerk nu zijn CosmosDBInput.
    • Doorgaans moet Output worden toegevoegd aan de naam van uitvoerbindingen. Als u bijvoorbeeld het Queue kenmerk uitvoerbinding in het procesmodel hebt gebruikt, zou dit kenmerk nu zijn QueueOutput.

  4. Werk de kenmerkparameters bij om de geïsoleerde versie van het werkmodel weer te geven, zoals is opgegeven in de referentiedocumentatie van de binding.

    In het procesmodel wordt bijvoorbeeld een blob-uitvoerbinding vertegenwoordigd door een [Blob(...)] kenmerk dat een Access instelling bevat. In het geïsoleerde werkermodel zou het kenmerk blob-uitvoer zijn [BlobOutput(...)]. Voor de binding is de Access eigenschap niet meer vereist, zodat de parameter kan worden verwijderd. Dus [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] zou het worden [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Uitvoerbindingen uit de lijst met functieparameters verplaatsen. Als u slechts één uitvoerbinding hebt, kunt u deze toepassen op het retourtype van de functie. Als u meerdere uitvoerwaarden hebt, maakt u een nieuwe klasse met eigenschappen voor elke uitvoer en past u de kenmerken toe op deze eigenschappen. Zie Meerdere uitvoerbindingen voor meer informatie.

  6. Raadpleeg de referentiedocumentatie van elke binding voor de typen waarmee u verbinding kunt maken. In sommige gevallen moet u mogelijk het type wijzigen. Voor uitvoerbindingen kunt u, als de versie van het procesmodel een IAsyncCollector<T>heeft gebruikt, deze vervangen door een binding met een matrix van het doeltype: T[] U kunt ook overwegen om de uitvoerbinding te vervangen door een clientobject voor de service die deze vertegenwoordigt, als het bindingstype voor een invoerbinding, indien beschikbaar, of door zelf een client te injecteren.

  7. Als uw functie een IBinder parameter bevat, verwijdert u deze. Vervang de functionaliteit door een clientobject voor de service die het voorstelt, als het bindingstype voor een invoerbinding, indien beschikbaar, of door zelf een client in te voeren.

  8. Werk de functiecode bij om te werken met nieuwe typen.

local.settings.json-bestand

Het local.settings.json-bestand wordt alleen gebruikt wanneer het lokaal wordt uitgevoerd. Zie het bestand Met lokale instellingen voor meer informatie.

Wanneer u migreert van in-proces naar uitvoering in een geïsoleerd werkproces, moet u de FUNCTIONS_WORKER_RUNTIME waarde wijzigen in dotnet-geïsoleerd. Zorg ervoor dat uw local.settings.json bestand ten minste de volgende elementen bevat:

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

De waarde die u hebt voor AzureWebJobsStorage kan anders zijn. U hoeft de waarde ervan niet te wijzigen als onderdeel van de migratie.

host.json bestand

Er zijn geen wijzigingen vereist voor uw host.json-bestand . Als uw Application Insights-configuratie zich echter in dit bestand bevindt vanuit uw in-process modelproject, wilt u mogelijk aanvullende wijzigingen aanbrengen in uw Program.cs-bestand . Het host.json bestand controleert alleen de logboekregistratie van de Functions-hostruntime, en in het model met geïsoleerde werkrollen komen sommige van deze logboeken rechtstreeks van uw toepassing, waardoor u meer controle hebt. Zie Logboekniveaus beheren in het geïsoleerde werkrolmodel voor meer informatie over het filteren van deze logboeken.

Andere codewijzigingen

In deze sectie worden andere codewijzigingen gemarkeerd die u kunt overwegen tijdens het uitvoeren van de migratie. Deze wijzigingen zijn niet nodig voor alle toepassingen, maar u moet evalueren of deze relevant zijn voor uw scenario's.

JSON-serialisatie

Het geïsoleerde werkrolmodel maakt standaard gebruik van System.Text.Json voor JSON-serialisatie. Zie Aanpassen van JSON-serialisatie als u serialisatieopties wilt aanpassen of wilt overschakelen naar JSON.NET (Newtonsoft.Json).

Application Insights-logboekniveaus en -filters

Logboeken kunnen vanuit zowel de Functions-hostruntime als code in uw project naar Application Insights worden verzonden. Met dehost.json kunt u regels voor hostlogboekregistratie configureren, maar om logboeken te beheren die afkomstig zijn van uw code, moet u filterregels configureren als onderdeel van uw Program.cs. Zie Logboekniveaus beheren in het geïsoleerde werkrolmodel voor meer informatie over het filteren van deze logboeken.

Voorbeeld van functiemigraties

Voorbeeld van HTTP-trigger

Een HTTP-trigger voor het in-procesmodel kan er als volgt uitzien:

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

Een HTTP-trigger voor de gemigreerde versie kan er als volgt uitzien:

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

Uw functie-app bijwerken in Azure

Het bijwerken van uw functie-app naar het geïsoleerde model omvat twee wijzigingen die samen moeten worden voltooid, omdat als u er maar één voltooit, de app een foutstatus heeft. Beide wijzigingen zorgen er ook voor dat het app-proces opnieuw wordt opgestart. Daarom moet u de update uitvoeren met behulp van een staging-slot. Faseringssites helpen de downtime voor uw app te minimaliseren en u kunt uw gemigreerde code testen en verifiëren met uw bijgewerkte configuratie in Azure. Vervolgens kunt u uw volledig gemigreerde app implementeren naar het productieslot middels een wisselbewerking.

Belangrijk

Wanneer de geïmplementeerde nettolading van een app niet overeenkomt met de geconfigureerde runtime, heeft deze een foutstatus. Tijdens het migratieproces plaatst u de app in deze status, idealiter slechts tijdelijk. Implementatieslots helpen dit effect te beperken, omdat de fouttoestand wordt opgelost in uw testomgeving (niet-productieomgeving) voordat de wijzigingen als één enkele update op uw productieomgeving worden toegepast. Slots beschermen ook tegen fouten en maken het mogelijk om eventuele andere problemen te detecteren voordat u de productie bereikt.

Tijdens het proces ziet u mogelijk nog steeds fouten in logboeken die afkomstig zijn van uw testomgeving (niet-productieve). Dit wordt verwacht, maar deze zouden moeten verdwijnen naarmate u de stappen doorloopt. Voordat u de slotwisselingsbewerking uitvoert, moet u controleren of deze fouten niet meer worden opgeroepen en dat uw toepassing werkt zoals verwacht.

Gebruik de volgende stappen om implementatieslots te gebruiken om uw functie-app om te zetten naar het geïsoleerde werknemermodel.

  1. Maak een implementatieslot als u dat nog niet hebt gedaan. Wellicht wilt u ook inzicht krijgen in het wisselen van slots en ervoor zorgen dat u de bestaande toepassing met minimale onderbreking kunt bijwerken.

  2. Wijzig de configuratie van de stagingomgeving (niet-productie) om het geïsoleerde werkermodel te gebruiken door de FUNCTIONS_WORKER_RUNTIME applicatie-instelling in te stellen op dotnet-isolated. FUNCTIONS_WORKER_RUNTIME mag niet worden gemarkeerd als een slot-instelling.

    Als u zich ook richt op een andere versie van .NET als onderdeel van uw update, moet u ook de stackconfiguratie wijzigen. Zie De stackconfiguratie bijwerken om dit te doen. U kunt dezelfde instructies gebruiken voor toekomstige .NET-versie-updates die u maakt.

    Als u geautomatiseerde infrastructuurvoorziening hebt, zoals een CI/CD-pijplijn, moet u ervoor zorgen dat automatiseringen ook worden bijgewerkt, zodat FUNCTIONS_WORKER_RUNTIME ingesteld blijft op dotnet-isolated en de juiste .NET-versie wordt gebruikt.

  3. Publiceer uw gemigreerde project naar de staging- (niet-productie) slot van uw functie-app.

    Als u Visual Studio gebruikt om een geïsoleerd werkrolmodelproject te publiceren naar een bestaande app of site die gebruikmaakt van het in-procesmodel, kan de vorige stap ook tegelijkertijd voor u worden voltooid. Als u de vorige stap niet hebt voltooid, wordt u in Visual Studio gevraagd om de functie-app bij te werken tijdens de implementatie. Visual Studio presenteert dit als één bewerking, maar dit zijn nog steeds twee afzonderlijke bewerkingen. Mogelijk ziet u tijdens de overgangsfase nog steeds fouten in uw logboeken van de staging-omgeving (niet-productie).

  4. Controleer of uw toepassing werkt zoals verwacht binnen de staging-omgeving (niet-productieomgeving).

  5. Voer een bewerking voor het wisselen van sites uit om de wijzigingen toe te passen die u in uw faseringssite (niet-productie) hebt aangebracht op de productiesite. Een slotwisseling vindt plaats als één update, waardoor de tussentijdse foutstatus in uw productieomgeving wordt vermeden.

  6. Controleer of uw toepassing werkt zoals verwacht in de productiesite.

Zodra u deze stappen hebt voltooid, is de migratie voltooid en wordt uw app uitgevoerd op het geïsoleerde model. Gefeliciteerd Herhaal de stappen uit deze handleiding indien nodig voor andere apps die migratie nodig hebben.

Volgende stap

Meer informatie over het geïsoleerde werkrolmodel