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

Artikel
04/07/2024

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 migratiehandleidingen voor 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-procesmodel^1,3
.NET 8²	LTS	Geïsoleerde werkrolmodel
.NET 7	STS (einde van ondersteuning 14 mei 2024)	Geïsoleerde werkrolmodel
.NET 6	LTS (einde van ondersteuning 12 november 2024)	Geïsoleerde werkrolmodel, In-process model³
.NET Framework 4.8	Beleid weergeven	Geïsoleerde werkrolmodel

¹ 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. Zie Verschillen tussen proces- en isoleerproces .NET Azure Functions voor een volledige functie en functionaliteitsvergelijking tussen de twee modellen.

² .NET 8 wordt nog niet ondersteund in het procesmodel, hoewel deze beschikbaar is in het geïsoleerde werkrolmodel. Zie het bericht Azure Functions Roadmap Update voor meer informatie over .NET 8-abonnementen, inclusief toekomstige opties voor het in-process model.

³ Ondersteuning eindigt op 10 november 2026 voor het in-procesmodel. Zie deze ondersteuningsaankondiging voor meer informatie. Voor continue volledige ondersteuning moet u uw apps migreren naar het geïsoleerde werkrolmodel.

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 7 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 naar het geïsoleerde werkrolmodel migreert, moet u de inhoud van deze handleiding grondig bekijken en 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:

Voer de stappen in Uw lokale project migreren uit om uw lokale project te migreren naar het geïsoleerde werkrolmodel.
Nadat u uw project hebt gemigreerd, test u de app volledig lokaal met versie 4.x van de Azure Functions Core Tools.
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.

Eerst converteert u het projectbestand en werkt u 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:

.NET 8
.NET Framework 4.8

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:

Stel de waarde van PropertyGroup.TargetFramework aan net8.0.
Stel de waarde van PropertyGroup.AzureFunctionsVersion aan v4.
Voeg het volgende element toe aan het PropertyGroupvolgende OutputType element:
```
<OutputType>Exe</OutputType>
```

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.

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>

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:

Stel de waarde van PropertyGroup.TargetFramework aan net48.
Stel de waarde van PropertyGroup.AzureFunctionsVersion aan v4.
Voeg het volgende element toe aan het PropertyGroupvolgende OutputType element:
```
<OutputType>Exe</OutputType>
```

In de ItemGroup.PackageReference vervang de pakketverwijzing door Microsoft.NET.Sdk.Functions de volgende verwijzingen:

  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
  <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" />

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

Voeg de volgende nieuwe ItemGrouptoe:

<ItemGroup>
  <Folder Include="Properties\" />
</ItemGroup>

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

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <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>

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

.NET 8
.NET Framework 4.8

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.

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

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 HostBuilderProgram.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 FunctionName kenmerk wordt vervangen door het Function kenmerk in het geïsoleerde werkrolmodel. 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 extra ILogger parameter toevoegen aan uw functie, of u kunt afhankelijkheidsinjectie gebruiken om een ILogger<T>. Als u al gebruikmaakt van afhankelijkheidsinjectie, 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:

Voeg in uw functieklasse een private readonly ILogger<MyFunction> _logger; eigenschap toe en vervang deze MyFunction door de naam van uw functieklasse.
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 bovenstaande codefragment door de naam van uw functieklasse.
Voor logboekregistratiebewerkingen in uw functiecode vervangt u verwijzingen naar de ILogger parameter door _logger.
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:

Verwijder eventuele using Microsoft.Azure.WebJobs; instructies.
Voeg een using Microsoft.Azure.Functions.Worker; instructie toe.
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, is CosmosDBInputdit nu .
- Uitvoerbindingen hebben doorgaans uitvoer nodig die aan hun naam is toegevoegd. Als u bijvoorbeeld het Queue kenmerk uitvoerbinding in het procesmodel hebt gebruikt, is QueueOutputdit nu .
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")].
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.
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.
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.
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 geconfigureerd 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:

.NET 8
.NET Framework 4.8

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

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

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = 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;
        }
    }
}

Uw functie-app bijwerken in Azure

Het upgraden van uw functie-app naar het geïsoleerde model bestaat uit twee stappen:

Wijzig de configuratie van de functie-app om het geïsoleerde model te gebruiken door de FUNCTIONS_WORKER_RUNTIME toepassingsinstelling in te dotnet-isolatedstellen op . Zorg ervoor dat alle automatisering van implementaties op dezelfde manier wordt bijgewerkt.
Publiceer uw gemigreerde project naar de bijgewerkte functie-app.

Wanneer u Visual Studio gebruikt om een geïsoleerd werkrolmodelproject te publiceren naar een bestaande functie-app die gebruikmaakt van het in-procesmodel, wordt u gevraagd om Visual Studio de functie-app tijdens de implementatie bij te werken. Hierdoor worden beide stappen tegelijk uitgevoerd.

Als u downtime wilt minimaliseren, kunt u overwegen om een staging-site te gebruiken om uw gemigreerde code te testen en te verifiëren met uw bijgewerkte configuratie in Azure. Vervolgens kunt u uw volledig gemigreerde app implementeren naar de productiesite via een wisselbewerking.

Zodra u deze stappen hebt voltooid, is uw app volledig gemigreerd naar 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