Share via

.NET-apps migreren van het in-procesmodel naar het geïsoleerde werkrolmodel

  • Artikel

Belangrijk

De ondersteuning wordt beëindigd voor het in-process model 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, volgt u in plaats daarvan de handleidingen voor het upgraden van uw hostversie:

Deze handleidingen voor migratie van hostversies helpen u ook bij het migreren naar het geïsoleerde werkrolmodel terwijl u ze doorloopt.

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 een abonnement dat momenteel door Azure PowerShell is geconfigureerd voor gebruik. 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 wanneer u het in-process model 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 Preview3 Geïsoleerde werkrolmodel
.NET 8 LTS (einde van ondersteuning 10 november 2026) Geïsoleerde werkrolmodel,
In-process model2
.NET 6 LTS (einde van ondersteuning 12 november 2024) Geïsoleerde werkrolmodel,
In-process model2
.NET Framework 4.8 Beleid weergeven Geïsoleerde werkrolmodel

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 continue volledige ondersteuning moet u uw apps migreren naar het geïsoleerde werkrolmodel.

3 Zie Preview .NET-versies in het geïsoleerde werkrolmodel voor meer informatie over ondersteuning, huidige beperkingen en instructies voor het gebruik van de preview-versie.

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 (preview) of .NET 6. Als u deze versies wilt toepassen, kunt u de .NET 8-voorbeelden aanpassen.

Voorbereiden op migratie

Als u dat nog niet hebt gedaan, identificeert u de lijst met apps die moeten worden gemigreerd in uw huidige Azure-abonnement met behulp van Azure PowerShell.

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.

Als u de toepassing wilt migreren, gaat u als volgt te werk:

  1. Migreer uw lokale project naar het geïsoleerde werkrolmodel door de stappen in Uw lokale project migreren uit te voeren.
  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. Bij deze stappen wordt uitgegaan van een lokaal C#-project en als uw app in plaats daarvan C#-script (.csx bestanden) gebruikt, moet u converteren naar het projectmodel voordat u doorgaat.

Tip

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

Converteer eerst het projectbestand en werk uw afhankelijkheden bij. Zoals u doet, ziet u buildfouten 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 6 op versie 4.x:

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

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 en 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 .csproj XML-projectbestand:

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

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

  3. Voeg het volgende element toe aan het PropertyGroupvolgende OutputType element:

    <OutputType>Exe</OutputType>

  4. In de ItemGroup.PackageReference vervang de pakketverwijzing door Microsoft.NET.Sdk.Functions 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 van .vscode/settings.json uw project. Controleer op eventuele afhankelijkheden van de frameworkversie die mogelijk buiten uw projectcode bestaan, 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 Replace
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 Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Wachtrijbindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabelbindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Tables
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindingen Verwijzingen vervangen 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 Verwijzingen vervangen naar
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
Event Grid-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.EventGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.SignalRService
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.DurableTask
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(SQL Storage-provider)		 Verwijzingen vervangen naar
Microsoft.DurableTask.SqlServer.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Netherite-opslagprovider)		 Verwijzingen vervangen naar
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.SendGrid
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka-bindingen Verwijzingen vervangen naar
Microsoft.Azure.WebJobs.Extensions.Kafka
met de nieuwste versie van
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ bindingen Verwijzingen vervangen 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 kunt deze ook bijwerken. 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.

bestand Program.cs

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 vervangen door ConfigureFunctionsWebApplication 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 to-ASP.NET Core behouden.

Het Program.cs bestand vervangt elk bestand dat het FunctionsStartup kenmerk heeft. Dit is meestal een Startup.cs bestand. Op plaatsen waarnaar uw FunctionsStartup code zou verwijzen IFunctionsHostBuilder.Services, kunt u in plaats daarvan instructies toevoegen binnen de .ConfigureServices() methode van de in uw HostBuilder Program.cs. Voor meer informatie over het werken met Program.cs, raadpleegt u Opstart- en configuratiehandleiding in de handleiding voor geïsoleerde werkrollen.

De bovenstaande standaardvoorbeelden Program.cs omvatten het instellen van Application Insights-integratie voor het geïsoleerde werkrolmodel. Program.csU moet 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 Program.csconfigureert, 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, moet u er rekening mee houden dat deze op dezelfde manier van toepassing zijn op code in uw project. De trigger- en bindingsconfiguratie is ook nodig voor het platform. 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>
  • Trigger- en bindingskenmerken 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 alleen een tekenreeksvervanging uitvoeren in uw project.

Logboekregistratie

In het procesmodel kunt u een optionele ILogger parameter toevoegen aan uw functie 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. Het wordt aanbevolen om afhankelijkheidsinjectie te gebruiken om een ILogger<T>. 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.

Zie Logboekregistratie in het geïsoleerde werkrolmodel voor meer informatie.

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 gaat oplossen:

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

  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.
    • Invoerbindingen hebben doorgaans 'Invoer' nodig die aan hun naam is toegevoegd. Als u bijvoorbeeld het CosmosDB kenmerk invoerbinding in het procesmodel hebt gebruikt, zou het kenmerk nu zijn CosmosDBInput.
    • Uitvoerbindingen hebben doorgaans uitvoer nodig die aan hun naam is toegevoegd. 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 blobuitvoerbinding vertegenwoordigd door een [Blob(...)] kenmerk dat een Access eigenschap bevat. In het geïsoleerde werkrolmodel zou het kenmerk blobuitvoer 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-isolated'. 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', is mogelijk anders. U hoeft de waarde ervan niet te wijzigen als onderdeel van de migratie.

host.json bestand

Er zijn geen wijzigingen in het host.json bestand vereist. Als uw Application Insights-configuratie in dit bestand echter vanuit uw in-process modelproject wordt uitgevoerd, wilt u mogelijk aanvullende wijzigingen aanbrengen in uw Program.cs bestand. Het host.json bestand beheert alleen logboekregistratie van de Functions-hostruntime en in het geïsoleerde werkrolmodel zijn sommige van deze logboeken rechtstreeks afkomstig van uw toepassing, zodat 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

Standaard wordt het geïsoleerde werkrolmodel gebruikt System.Text.Json voor JSON-serialisatie. Als u serialisatieopties wilt aanpassen of wilt overschakelen naar JSON.NET (Newtonsoft.Json), raadpleegt u deze instructies.

Application Insights-logboekniveaus en -filters

Logboeken kunnen vanuit zowel de Functions-hostruntime als code in uw project naar Application Insights worden verzonden. Hiermee host.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-site. 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 de productiesite via 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, in het ideale instantie slechts tijdelijk. Implementatiesites helpen de impact hiervan te beperken, omdat de foutstatus wordt opgelost in uw faseringsomgeving (niet-productie) voordat de wijzigingen worden toegepast als één update voor uw productieomgeving. Sites beschermen zich ook tegen fouten en stellen u in staat 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 faseringssite (niet-productiesite). Dit wordt verwacht, hoewel deze moeten verdwijnen terwijl u doorgaat met de stappen. Voordat u de sitewisselingsbewerking uitvoert, moet u controleren of deze fouten niet meer worden gegenereerd en dat uw toepassing werkt zoals verwacht.

Gebruik de volgende stappen om implementatiesites te gebruiken om uw functie-app bij te werken naar het geïsoleerde werkrolmodel:

  1. Maak een implementatiesite als u dat nog niet hebt gedaan. Mogelijk wilt u ook vertrouwd raken met het proces voor het wisselen van sites en ervoor zorgen dat u met minimale onderbreking updates aan de bestaande toepassing kunt aanbrengen.

  2. Wijzig de configuratie van de faseringssite (niet-productiesite) om het geïsoleerde werkrolmodel te gebruiken door de FUNCTIONS_WORKER_RUNTIME toepassingsinstelling in te dotnet-isolatedstellen op . FUNCTIONS_WORKER_RUNTIME mag niet worden gemarkeerd als een 'site-instelling'.

    Als u zich ook richt op een andere versie van .NET als onderdeel van uw update, moet u ook de stackconfiguratie wijzigen. Raadpleeg hiervoor de instructies voor het bijwerken van de stackconfiguratie voor het geïsoleerde werkrolmodel. U gebruikt dezelfde instructies voor toekomstige .NET-versie-updates die u maakt.

    Als u automatische infrastructuurinrichting hebt, zoals een CI/CD-pijplijn, moet u ervoor zorgen dat de automatiseringen ook worden bijgewerkt om ingesteld te blijven FUNCTIONS_WORKER_RUNTIME dotnet-isolated op en de juiste .NET-versie te bereiken.

  3. Publiceer uw gemigreerde project naar de faseringssite (niet-productiesite) 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 tussentijdse status nog steeds fouten in uw logboeken van de faseringssite (niet-productiesite).

  4. Controleer of uw toepassing werkt zoals verwacht in de staging-site (niet-productiesite).

  5. Voer een sleufwisselingsbewerking uit. Hiermee worden de wijzigingen toegepast die u hebt aangebracht in uw faseringssite (niet-productiesite) op de productiesite. Een sitewisseling vindt plaats als één update, waardoor de tussentijdse foutstatus in uw productieomgeving niet wordt ingevoerd.

  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 alle andere apps die migratie nodig hebben.

Volgende stappen

Meer informatie over het geïsoleerde werkrolmodel