Migrera C#-appar från den pågående modellen till den isolerade arbetsmodellen

Viktigt!

Stödet för den processbaserade modellen upphör den 10 november 2026. Migrera dina appar till modellen för isolerad arbetare genom att följa instruktionerna i denna artikel.

Den här artikeln beskriver hur du migrerar .NET funktion app från inprocessmodellen till isolerad arbetsmodell. Mer information om skillnaderna på hög nivå mellan dessa modeller finns i jämförelsen av körningsläge.

Den här guiden förutsätter att din app kör version 4.x av Functions runtime. Om inte, använd följande guider för att uppgradera din värdversion. De här migreringsguiderna för värdversion hjälper dig också att migrera till den isolerade arbetsmodellen när du arbetar med dem.

När den här artikeln stöds utnyttjar den ASP.NET Core integrering i den isolerade arbetsmodellen, vilket förbättrar prestanda och ger en välbekant programmeringsmodell när din app använder HTTP-utlösare.

Identifiera funktionsappar som ska migreras

Använd följande Azure PowerShell skript för att generera en lista över funktionsappar i din prenumeration som för närvarande använder den pågående modellen.

Skriptet använder den prenumeration som Azure PowerShell för närvarande är konfigurerad att använda. Du kan ändra prenumerationen genom att först köra Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' och ersätta <YOUR SUBSCRIPTION ID> med ID:t för den prenumeration du vill utvärdera.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Välj målversion .NET

När du migrerar till modellen för isolerad arbetare, välj ditt mål baserat på om din funktionsapp och dess beroenden kan köras på .NET (tidigare .NET Core):

  • Om din app och dess beroenden kan köras på .NET, sikta på .NET 10.
  • Om din app är beroende av bibliotek eller API:er som endast finns i .NET Framework, sikta på .NET Framework 4.8.

Förbereda för migrering

Innan du migrerar en app till modellen för isolerad arbetare, granska noggrant innehållet i denna guide. Sätt dig också in i egenskaperna hos modellen med isolerad arbetare och skillnaderna mellan de två modellerna.

Så här migrerar du programmet:

  1. Migrera ditt lokala projekt till den isolerade arbetsmodellen genom att följa stegen i Migrera ditt lokala projekt.
  2. Efter att du migrerat ditt projekt, testa appen lokalt helt genom att använda version 4.x av Azure Functions Core Tools.
  3. Update din funktionsapp i Azure till den isolerade modellen.

Migrera ditt lokala projekt

Detta avsnitt beskriver de olika ändringar du behöver göra i ditt lokala projekt för att flytta det till modellen för isolerad arbetare. Vissa av stegen ändras baserat på målversionen av .NET. Använd flikarna för att välja de instruktioner som matchar din önskade version.

Tips

Om du går över till .NET 10 kan .NET Upgrade Assistant automatiskt göra många av de ändringar som nämns i följande avsnitt.

Konvertera först projektfilen och uppdatera dina beroenden. När du gör det upptäcker du byggfel i projektet. I efterföljande steg gör du motsvarande ändringar för att ta bort dessa fel.

projektfil

Följande exempel visar en .csproj-projektfil som använder .NET 8 på version 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>

Använd någon av följande procedurer för att uppdatera XML-filen så att den körs i den isolerade arbetsmodellen:

De här stegen förutsätter ett lokalt C#-projekt. Om din app i stället använder C#-skript (.csx-filer ) bör du konvertera till projektmodellen innan du fortsätter.

Följande ändringar krävs i XML-projektfilen .csproj :

  1. Sätt attributet Sdk på elementet Project till Azure.Functions.Sdk/1.0.0.

  2. Ange värdet för PropertyGroup. TargetFramework till net10.0.

  3. ItemGroup. PackageReference lista, ersätt paketreferensen till Microsoft.NET.Sdk.Functions med följande referenser. Behåll paketet Microsoft.Azure.Functions.Worker som en explicit referens:

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

    Anteckna eventuella referenser till andra paket i namnrymderna Microsoft.Azure.WebJobs.*. Du ersätter dessa paket i ett senare steg.

  4. Lägg till följande nya ItemGroup:

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

När du har genomfört de här ändringarna bör ditt uppdaterade projekt se ut som i följande exempel:

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

Att ändra projektets målramverk kan också kräva ändringar i delar av verktygskedjan, utanför projektkoden. I VS Code kan du till exempel behöva uppdatera tilläggsinställningen azureFunctions.deploySubpath via användarinställningar eller projektets .vscode/settings.json-fil . Sök efter eventuella beroenden för den ramverksversion som kan finnas utanför projektkoden, som en del av byggstegen eller en CI/CD-pipeline.

Paketreferenser

När du migrerar till modellen för isolerad arbetare, ändra de paket som din applikation refererar till.

Om du inte redan gjort det, uppdatera ditt projekt för att använda de senaste stabila versionerna av:

Beroende på vilka utlösare och bindningar som appen använder kan din app behöva referera till en annan uppsättning paket. I följande tabell visas ersättningarna för några av de vanligaste tilläggen:

Scenario Ändringar i paketreferenser
Timerutlösare Lägg till
Microsoft.Azure. Functions.Worker.Extensions.Timer
Lagringsbindningar Replace
Microsoft.Azure.WebJobs.Extensions.Storage
med
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues och
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blobbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs
Köbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Tabellbindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Tables
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.CosmosDB
och/eller
Microsoft.Azure.WebJobs.Extensions.DocumentDB
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.CosmosDB
Service Bus kopplingar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.ServiceBus
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.ServiceBus
Event Hubs-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.EventHubs
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.EventHubs
bindningar för Event Grid Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.EventGrid
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.EventGrid
SignalR Service bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.SignalRService
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.SignalRService
Varaktiga Funktioner Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.DurableTask
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Varaktiga Funktioner
(SQL-lagringsprovider)		 Ersätt referenser till
Microsoft.DurableTask.SqlServer.AzureFunctions
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Varaktiga Funktioner
(Netherite Storage-provider)		 Ersätt referenser till
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.Netherite
SendGrid-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.SendGrid
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.SendGrid
Kafka-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.Kafka
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.Kafka
RabbitMQ-bindningar Ersätt referenser till
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
med den senaste versionen av
Microsoft.Azure. Functions.Worker.Extensions.RabbitMQ
Beroendeinjektion
och startkonfiguration		 Ta bort referenser till
Microsoft.Azure.Functions.Extensions
(Den isolerade arbetsmodellen tillhandahåller den här funktionen som standard.)

Se Bindningar som stöds för en fullständig lista över tillägg att överväga och läs dokumentationen för varje tillägg för fullständiga installationsinstruktioner för den isolerade processmodellen. Se till att installera den senaste stabila versionen av alla paket som du riktar in dig på.

Tips

Eventuella ändringar av tilläggsversioner under den här processen kan kräva att du även uppdaterar host.json filen. Läs dokumentationen för varje tillägg som du använder. Till exempel har Service Bus-tillägget icke-bakåtkompatibla ändringar i strukturen mellan versionerna 4.x och 5.x. Mer information finns i Azure Service Bus-bindingar för Azure Functions.

Ditt isolerade arbetsmodellprogram bör inte referera till några paket i namnrymderna Microsoft.Azure.WebJobs.* eller Microsoft.Azure.Functions.Extensions. Om du har några återstående referenser till dessa bör de tas bort.

Tips

Din app kan också vara beroende av Azure SDKs typer, antingen som en del av dina utlösare och bindningar eller som ett fristående beroende. Du bör också ta tillfället i akt att uppdatera dessa. De senaste versionerna av Functions-tilläggen fungerar med de senaste versionerna av Azure SDKs för .NET, nästan alla paket som har formatet Azure.*.

Program.cs fil

När du migrerar till att köras i en isolerad arbetsprocess, lägg till en Program.cs-fil i ditt projekt med följande innehåll:

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

Det här exemplet omfattar ASP.NET Core integrering för att förbättra prestanda och tillhandahålla en välbekant programmeringsmodell när din app använder HTTP-utlösare. Om du inte tänker använda HTTP-utlösare kan du ersätta anropet till ConfigureFunctionsWebApplication med ett anrop till ConfigureFunctionsWorkerDefaults. Om du gör det kan du ta bort referensen till Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore från projektfilen. Men för bästa prestanda, även för funktioner med andra utlösartyper, bör du behålla FrameworkReference till ASP.NET Core.

Filen Program.cs ersätter alla filer som har FunctionsStartup attributet , vilket vanligtvis är en Startup.cs fil. På platser där koden FunctionsStartup refererar till IFunctionsHostBuilder.Services kan du i stället lägga till instruktioner i .ConfigureServices()-metoden av HostBuilder i din Program.cs. Mer information om hur du arbetar med Program.cs finns i Start-up and configuration in the isolated worker model guide (Starta och konfigurera i den isolerade arbetsmodellguiden).

De tidigare beskrivna standardexemplen Program.cs sätter upp Application Insights genom att använda Application Insights SDK. För den OpenTelemetry-baserade Application Insights-konfigurationen som beskrivs i guiden för modellen för isolerade arbetare, se Application Insights. I din Program.cs måste du också konfigurera loggfiltrering som ska gälla för loggar som kommer från kod i projektet. I den isolerade arbetsmodellen styr host.json-filen endast händelser som genereras av Functions-värdkörningen. Om du inte konfigurerar filtreringsregler i Program.cs kan du se skillnader i loggnivåerna för olika kategorier i telemetrin.

Även om du kan registrera anpassade konfigurationskällor som en del av HostBuilder, gäller dessa på samma sätt endast för kod i projektet. Plattformen behöver också utlösar- och bindningskonfiguration, och detta bör tillhandahållas via application-inställningarna, Key Vault referenser eller Appkonfigurationsreferenser funktioner.

När du har flyttat allt från alla befintliga FunctionsStartup till Program.cs-filen kan du ta bort FunctionsStartup attributet och den klass som det tillämpades på.

Ändringar i funktionssignatur

Vissa nyckeltyper ändras mellan den processbaserade modellen och den isolerade arbetsmodellen. Många av dessa förändringar rör attributen, parametrarna och returtyperna som utgör funktionssignaturen. För varje av dina funktioner, gör ändringar i:

  • Funktionsattributet, som även anger funktionens namn
  • Hur funktionen hämtar en ILogger/ILogger<T>
  • Utlösar- och bindningsattribut och parametrar

Resten av det här avsnittet beskriver vart och ett av de här stegen.

Funktionsattribut

Attributet Function i den isolerade arbetsmodellen ersätter attributet FunctionName . Det nya attributet har samma signatur och den enda skillnaden är i namnet. Du kan därför ersätta en sträng i hela projektet.

Loggning

I den processbaserade modellen kan du inkludera en valfri ILogger parameter för din funktion, eller så kan du använda beroendeinmatning för att hämta en ILogger<T>. Om din app redan har använt beroendeinmatning fungerar samma mekanismer i den isolerade arbetsmodellen.

För funktioner som förlitade sig på ILogger metodparametern måste du dock göra en ändring. Använd beroendeinjektion för att få en ILogger<T>. Använd följande steg för att migrera funktionens loggningsmekanism:

  1. I funktionsklassen lägger du till en private readonly ILogger<MyFunction> _logger; egenskap som ersätter MyFunction med namnet på din funktionsklass.

  2. Skapa en konstruktor för din funktionsklass som tar in ILogger<T> som en parameter:

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

    Ersätt båda instanserna av MyFunction i föregående kodfragment med namnet på din funktionsklass.

  3. För loggningsåtgärder i funktionskoden ersätter du referenser till parametern ILogger med _logger.

  4. Ta bort parametern ILogger från funktionssignaturen.

Mer information finns i Loggning i den isolerade arbetsmodellen.

Utlösar- och bindningsändringar

När du ändrade paketreferenserna i ett tidigare steg introducerade du fel för dina utlösare och bindningar som du nu kan åtgärda:

  1. Ta bort alla using Microsoft.Azure.WebJobs;-instruktioner.

  2. Lägg till en using Microsoft.Azure.Functions.Worker;-instruktion.

  3. För varje bindningsattribut ändrar du attributets namn enligt beskrivningen i referensdokumentationen, som du hittar i indexet Bindningar som stöds. I allmänhet ändras attributnamnen enligt följande:

    • Utlösare förblir vanligtvis namngivna på samma sätt. Är till exempel QueueTrigger attributnamnet för båda modellerna.
    • Indatabindningar behöver vanligtvis få Input tillagda i sina namn. Om du till exempel använde indatabindningsattributet CosmosDB i inprocessmodellen skulle attributet nu vara CosmosDBInput.
    • Utdatabindningar behöver Output vanligtvis läggas till i namnet. Om du till exempel använde utdatabindningsattributet Queue i in-process-modellen skulle det här attributet nu vara QueueOutput.

  4. Uppdatera attributparametrarna så att de återspeglar den isolerade arbetsmodellversionen enligt beskrivningen i bindningens referensdokumentation.

    I den processbaserade modellen representeras till exempel en blobutdatabindning av ett [Blob(...)] attribut som innehåller en Access egenskap. I den isolerade arbetsmodellen skulle blobutdataattributet vara [BlobOutput(...)]. Bindningen kräver inte längre egenskapen Access , så du kan ta bort den parametern. Så [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] blir [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Flytta utdatabindningar från funktionsparameterlistan. Om du bara har en output-binding kan du applicera denna binding på returtypen av funktionen. Om du har flera utdata skapar du en ny klass med egenskaper för varje utdata och tillämpar attributen på dessa egenskaper. Mer information finns i Flera utdatabindningar.

  6. Läs referensdokumentationen för varje bindning för de typer som du kan binda till. I vissa fall kan du behöva ändra typen. För utdatabindningar, om versionen av modellen i processen använde typen IAsyncCollector<T>, kan du ersätta den här typen genom att binda till en matris av måltypen: T[]. Du kan också överväga att ersätta utdatabindningen med ett klientobjekt för den tjänst som den representerar, antingen som bindningstyp för en indatabindning om den är tillgänglig eller genom att mata in en klient själv.

  7. Om funktionen innehåller en IBinder parameter tar du bort den. Ersätt funktionen med ett klientobjekt för den tjänst som den representerar, antingen som bindningstyp för en indatabindning om den är tillgänglig, eller genom att mata in en klient själv.

  8. Uppdatera funktionskoden så att den fungerar med alla nya typer.

Migrera till asynkron HTTP-ström-I/O

Om en HTTP-utlöst funktion använder ASP.NET Core-integration, ersätt synkrona läsningar från och skrivningar till HTTP-förfrågnings- och svarsströmmar med asynkrona metoder. Synkrona operationer kan misslyckas med InvalidOperationException: Synchronous operations are disallowed. Till exempel, ersätt ReadToEnd med ReadToEndAsync, Write med WriteAsync, WriteString med WriteStringAsync, och Flush med FlushAsync.

När du väntar på dessa operationer, markera funktionsmetoden som async och linda in dess returtyp i Task<T>. Till exempel, ändra IActionResult till Task<IActionResult> eller MultiResponse till .Task<MultiResponse> ASP.NET Core förbjuder synkron I/O för förfrågningar och svar som standard eftersom synkron I/O kan orsaka svält i trådpoolen. Om ett beroende eller en serialiserare inte stödjer asynkron I/O, se JSON-serialisering med ASP.NET Core-integration för instruktioner som möjliggör synkron I/O (AllowSynchronousIO) som ett kompatibilitetsalternativ.

local.settings.json fil

Filen local.settings.json används endast när den körs lokalt. Mer information finns i Filen Lokala inställningar.

När du migrerar från att köras i processen till att köras i en isolerad arbetsprocess måste du ändra FUNCTIONS_WORKER_RUNTIME värdet till dotnet-isolerad. Se till att din local.settings.json-fil innehåller minst följande element:

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

Värdet du har för AzureWebJobsStorage kan vara annorlunda. Du behöver inte ändra dess värde som en del av migreringen.

host.json-fil

Inga ändringar krävs för dinhost.json-fil . Men om Application Insights-konfigurationen finns i den här filen från ditt processmodellprojekt kanske du vill göra fler ändringar i din Program.cs-fil . host.json-filen styr bara loggning från Functions-värdens körningsmiljö. I modellen med isolerad arbetare kommer några av dessa loggar direkt från din applikation, vilket ger dig mer kontroll. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .

Andra kodändringar

I det här avsnittet beskrivs andra kodändringar som du bör tänka på när du arbetar med migreringen. Dessa ändringar behövs inte av alla program, men du bör utvärdera om några är relevanta för dina scenarier.

JSON-serialisering

Som standard använder den isolerade arbetsmodellen System.Text.Json för JSON-serialisering. Om du vill anpassa serialiseraralternativ eller växla till JSON.NET (Newtonsoft.Json) kan du läsa Anpassa JSON-serialisering.

Eftersom den pågående modellen använde Newtonsoft.Json, kontrollera också serialiseringsattributen på alla typer som dina funktioner binder till. System.Text.Json ignorerar attribut som [JsonProperty] och [JsonIgnore] från Newtonsoft.Json. Den binder den berörda egenskapen till dess standardvärde utan att rapportera något fel. Antingen ersätter du dem med deras System.Text.Json-motsvarigheter , såsom [JsonPropertyName], eller konfigurerar Newtonsoft.Json för lagret som hanterar nyttolasten.

Application Insights-loggnivåer och filtrering

Loggar kan skickas till Application Insights från både körmiljön för Functions och projektkoden. Med host.json kan du konfigurera regler för värdloggning, men för att styra loggar som kommer från koden måste du konfigurera filtreringsregler som en del av din Program.cs. Mer information om hur du filtrerar loggarna finns i Hantera loggnivåer i den isolerade arbetsmodellen .

Exempel på migrering av HTTP-triggern

Följande exempel jämför en HTTP-utlöst funktion före och efter migrering med den isolerade arbetarmodellen.

En HTTP-utlösare för den processbaserade modellen kan se ut som i följande exempel:

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

En HTTP-utlösare för den migrerade versionen kan se ut som i följande exempel:

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

Uppdatera funktionsappen i Azure

Efter att du migrerat ditt lokala projekt, uppdatera konfigurationen av din funktionsapp och distribuera den migrerade koden för att slutföra flytten till den isolerade arbetsmodellen.

Innan du publicerar ditt migrerade projekt

Innan du publicerar ditt uppdaterade kodprojekt, planera att slutföra dessa två ändringar tillsammans:

  • Ändra applikationsinställningen FUNCTIONS_WORKER_RUNTIME till dotnet-isolated.
  • Publicera det migrerade projektet för isolerad arbetsprocess till din funktionsapp.

Varje ändring startar om appen. Efter att du har slutfört den första ändringen stämmer inte den distribuerade koden och konfigurerade runtime, vilket orsakar ett felmeddelande mellan runtime/payload (AZFD0013) tills du slutför den andra ändringen.

Använd när det är möjligt en uppställningsplats under migrationen. En scenplats ger dig dessa fördelar:

  • Håller det temporära feltillståndet som orsakas av bristande överensstämmelse mellan kod och körtid borta från produktion.
  • Låter dig testa den migrerade koden och konfigurationen innan du går in i produktion.

Du kan se fel i staging-slotloggarna när du genomför de två ändringarna. Innan du byter plats, kontrollera att felen har upphört och att appen fungerar som förväntat.

Uppdatera din funktionsapp genom att använda slots

Använd följande steg för att uppdatera din funktionsapp till den isolerade arbetsprocessmodellen med en mellanlagringsplats:

  1. Skapa en distributionsplats om du inte redan har gjort det. Du kanske också vill bekanta dig med växlingsprocessen för fack och se till att du kan göra uppdateringar av det befintliga programmet med minimala avbrott.

  2. Ändra konfigurationen av mellanlagringsplatsen (icke-produktionsplatsen) så att den isolerade arbetsmodellen används genom att ange programinställningen FUNCTIONS_WORKER_RUNTIME till dotnet-isolated. Markera FUNCTIONS_WORKER_RUNTIME inte som en platsinställning.

    Om du också siktar på en annan version av .NET som en del av din uppdatering, ändra stackkonfigurationen. Det gör du genom att läsa Uppdatera stackkonfigurationen. Du kan använda samma instruktioner för framtida .NET versionsuppdateringar som du gör.

    Om du har någon automatiserad provisionering av infrastruktur, till exempel en CI/CD-pipeline, ska du se till att automatiseringarna också uppdateras så att FUNCTIONS_WORKER_RUNTIME förblir inställt på dotnet-isolated och riktas mot rätt .NET-version.

  3. Publicera ditt migrerade projekt till mellanlagringsplatsen (icke-produktion) i funktionsappen.

    Om du använder Visual Studio för att publicera ett isolerat arbetsmodellprojekt till en befintlig app eller ett befintligt fack som använder den processbaserade modellen, kan det också slutföra föregående steg åt dig samtidigt. Om du inte slutförde föregående steg uppmanar Visual Studio dig att uppdatera funktionsappen under distributionen. Visual Studio presenterar denna uppdatering som en enda operation, men dessa uppdateringar är fortfarande två separata operationer. Du kan fortfarande se fel i loggarna från mellanlagringsplatsen (icke-produktion) under interimstillståndet.

  4. Bekräfta att din applikation fungerar som förväntat inom stagingmiljön (icke-produktionsmiljö).

  5. Utför en platsväxlingsåtgärd för att tillämpa de ändringar som du gjorde i mellanlagringsplatsen (icke-produktion) på produktionsplatsen. Ett fackbyte sker som en enskild uppdatering, vilket undviker att införa ett tillfälligt felaktigt tillstånd i produktionsmiljön.

  6. Bekräfta att din applikation fungerar som förväntat inom produktionsslotten.

När du har slutfört de här stegen är migreringen klar och appen körs på den isolerade modellen. Grattis! Upprepa stegen i den här guiden efter behov för andra appar som behöver migrering.

Nästa steg

Läs mer om att köra C# Azure Functions i den isolerade arbetsmodellen

  • Uppdaterades senast