Dela via

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. Vi rekommenderar starkt att du migrerar dina appar till den isolerade arbetsmodellen genom att följa anvisningarna i den här artikeln.

Den här artikeln beskriver hur du migrerar .NET-funktionsappen på ett säkert sätt från den pågående modellen till den isolerade arbetsmodellen. 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. Annars bör du använda följande guider för att uppgradera värdversionen. 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 drar den nytta av 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 konfigurerat att använda. Du kan ändra prenumerationen genom att först köra Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' och därefter ersätta <YOUR SUBSCRIPTION ID> med ID:t för den prenumeration som 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 din .NET-målversion

I version 4.x av Functions-körningsmiljön riktar sig .NET-funktionsappen mot .NET 6 eller .NET 8 när du använder den in-process modellen.

När du migrerar funktionsappen har du möjlighet att välja målversionen av .NET. Du kan uppdatera C#-projektet till någon av följande versioner av .NET som stöds av Functions version 4.x:

.NET-version Versionstyp för .NET Official Support Policy Funktionsprocessmodell1,2
.NET 9 STS (support upphör 12 maj 2026) Isolerad arbetsmodell
.NET 8 LTS (support upphör 10 november 2026) Isolerad arbetstagarmodell
Processmodell2
.NET Framework 4.8 Se princip Isolerad arbetsmodell

1 Den isolerade arbetsmodellen stöder versioner av .NET (Long Term Support) och Standard Term Support (STS) samt .NET Framework. Den processbaserade modellen stöder endast LTS-versioner av .NET, som slutar med .NET 8. En fullständig jämförelse av funktioner och funktionalitet mellan de två modellerna finns i Skillnader mellan in-process och isolerad arbetsprocess för .NET Azure Functions.

2 Supporten upphör för den pågående modellen den 10 november 2026. Mer information finns i det här supportmeddelandet. Om du vill ha fortsatt fullständigt stöd bör du migrera dina appar till den isolerade arbetsmodellen.

Tips

Vi rekommenderar att du uppgraderar till .NET 8 på den isolerade arbetsmodellen. Detta ger en enkel migreringsväg till den fullständiga versionen med .NET:s längsta supportperiod.

Den här guiden innehåller inte några specifika exempel för .NET 9. Om du behöver rikta in dig på den versionen kan du anpassa .NET 8-exemplen.

Förbereda för migrering

Innan du migrerar en app till den isolerade arbetsmodellen bör du noggrant granska innehållet i den här guiden. Du bör också bekanta dig med funktionerna i den isolerade arbetsmodellen 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. När du har migrerat projektet testar du appen lokalt med version 4.x av Azure Functions Core Tools.
  3. Uppdatera funktionsappen i Azure till den isolerade modellen.

Migrera ditt lokala projekt

I avsnittet beskrivs de olika ändringar som du behöver göra i ditt lokala projekt för att flytta det till den isolerade arbetsmodellen. 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 flyttar till en LTS- eller STS-version av .NET kan .NET Upgrade Assistant användas för att 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 är 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. Ange värdet för PropertyGroup. TargetFramework till net8.0.

  2. Ange värdet för PropertyGroup. AzureFunctionsVersion till v4.

  3. Lägg till följande OutputType element i PropertyGroup:

    <OutputType>Exe</OutputType>

  4. ItemGroup. PackageReference ersätt paketreferensen för Microsoft.NET.Sdk.Functions med följande referenser:

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

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

  5. 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="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>

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 den isolerade arbetsmodellen måste du ändra paketen som dina programreferenser refererar till.

Om du inte redan har gjort det uppdaterar du projektet så att det refererar till 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-bindningar 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
Tåliga funktioner
(SQL-lagringsprovider)		 Ersätt referenser till
Microsoft.DurableTask.SqlServer.AzureFunctions
med den senaste versionen av
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Hållbara 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. Service Bus-tillägget har till exempel icke-bakåtkompatibla ändringar i strukturen mellan versionerna 4.x och 5.x. Mer information finns i Azure Service Bus-bindningar för Azure Functions.

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

Dricks

Din app kan också vara beroende av Azure SDK-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 SDK för .NET, nästan alla av paketen är i formen Azure.*.

Program.cs fil

När du migrerar för att köras i en isolerad arbetsprocess måste du lägga till en Program.cs fil i projektet 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).

Standardexemplen för Program.cs som beskrevs tidigare är installation av 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 även utlösar- och bindningskonfiguration, och detta bör tillhandahållas via funktionerna för programinställningar, Key Vault-referenser eller appkonfigurationsreferenser .

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 gäller attribut, parametrar och returtyper som utgör funktionssignaturen. För var och en av dina funktioner måste du göra ä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 enkelt utföra en strängersättning över hela ditt projekt.

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. Vi rekommenderar att du använder dependency injection för att erhålla 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; uttalanden.

  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å att parametern kan tas bort. Så [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] skulle bli [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Flytta utdatabindningar från funktionsparameterlistan. Om du bara har en utdatabindning kan du tillämpa den på funktionens returtyp. 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. Om den processbaserade modellversionen använde en IAsyncCollector<T>för utdatabindningar kan du ersätta den med bindning 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.

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. Kontrollera att dinlocal.settings.json-fil har 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 pågående modellprojekt kanske du vill göra ytterligare ändringar i Program.cs-filen . Den host.json filen styr endast loggning från Functions-värdtjänstens körmiljö, och i den isolerade arbetsprocessmodellen kommer vissa av dessa loggar direkt från ditt program, 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) läser du Anpassa JSON-serialisering.

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

EXEMPEL på HTTP-utlösare

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

Uppdatera funktionsappen i Azure

När du uppdaterar funktionsappen till den isolerade modellen krävs två ändringar som ska slutföras tillsammans, för om du bara slutför en är appen i ett feltillstånd. Båda dessa ändringar gör också att appprocessen startas om. Därför bör du utföra uppdateringen med hjälp av ett mellanlagringsfack. Mellanlagringsplatser hjälper till att minimera stilleståndstiden för din app och gör att du kan testa och verifiera din migrerade kod med din uppdaterade konfiguration i Azure. Du kan sedan distribuera din fullständigt migrerade app till produktionsplats genom en swap-operation.

Viktigt!

När en apps distribuerade nyttolast inte matchar den konfigurerade körningen är den i ett feltillstånd. Under migreringsprocessen placerar du appen i det här tillståndet, helst endast tillfälligt. Distributionsplatser hjälper till att minska effekten av detta eftersom feltillståndet kommer att lösas i din mellanlagringsmiljö (icke-produktion) innan ändringarna tillämpas som en enda uppdatering i produktionsmiljön. Slots skyddar också mot eventuella misstag och gör att du kan identifiera andra problem innan du når produktion.

Under processen kan du fortfarande se fel i loggar som kommer från mellanlagringsplatsen (icke-produktion). Detta är förväntat, även om dessa bör försvinna när du fortsätter genom stegen. Innan du utför slotbyte bör du bekräfta att dessa fel inte längre uppstår och att din applikation som förväntat fungerar.

Använd följande steg för att använda distributionsplatser för att uppdatera funktionsappen till den isolerade arbetsmodellen:

  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. FUNCTIONS_WORKER_RUNTIME bör inte markeras som en platsinställning.

    Om du också riktar in dig på en annan version av .NET som en del av uppdateringen bör du också ändra stackkonfigurationen. Det gör du genom att läsa Uppdatera stackkonfigurationen. Du kan använda samma instruktioner för eventuella framtida .NET-versionsuppdateringar som du gör.

    Om du har någon automatiserad infrastrukturetablering, till exempel en CI/CD-pipeline, kontrollerar du att automatiseringarna också uppdateras för att hålla FUNCTIONS_WORKER_RUNTIME inställt på dotnet-isolated och för att rikta rätt version av .NET.

  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 även 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 detta som en enda åtgärd, men det är fortfarande två separata åtgärder. 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 den isolerade arbetsmodellen