Migrera .NET-appar från den pågående modellen till den isolerade arbetsmodellen

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örs på version 4.x av Functions-körningen. Annars bör du i stället följa guiderna för att uppgradera din värdversion:

• Migrera appar från Azure Functions version 2.x och 3.x till version 4.x
• Migrera appar från Azure Functions version 1.x till version 4.x

De här migreringsguiderna för värdversion hjälper dig också att migrera till den isolerade arbetsmodellen när du arbetar med dem.

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 en prenumeration som Azure PowerShell för närvarande är konfigurerat att använda. Du kan ändra prenumerationen genom att <YOUR SUBSCRIPTION ID> först köra Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' och ersätta 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örningen riktar sig .NET-funktionsappen mot .NET 6 när du använder inprocessmodellen.

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:

¹ 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 funktionsjämförelse och funktionsjämförelse mellan de två modellerna finns i Skillnader mellan processer och isolera arbetsprocess .NET Azure Functions.

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

³ Se Förhandsversioner av .NET i den isolerade arbetsmodellen för mer information om support, aktuella begränsningar och instruktioner för att använda förhandsversionen.

Den här guiden innehåller inte några specifika exempel för .NET 9 (förhandsversion) eller .NET 6. Om du behöver rikta in dig på dessa versioner kan du anpassa .NET 8-exemplen.

Förbereda för migrering

Om du inte redan har gjort det kan du identifiera listan över appar som måste migreras i din aktuella Azure-prenumeration med hjälp av Azure PowerShell.

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.

Om du vill migrera programmet gör du följande:

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. De här stegen förutsätter ett lokalt C#-projekt, och om din app i stället använder C#-skript (.csx filer) bör du konvertera till projektmodellen innan du fortsätter.

Konvertera först projektfilen och uppdatera dina beroenden. Precis som du ser byggfel för 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 6 på version 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>

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

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

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

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. Kontrollera om det finns 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:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

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:

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

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.

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

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

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 IFunctionsHostBuilder.Servicestill kan du i stället lägga till instruktioner i .ConfigureServices() -metoden HostBuilder i i .Program.cs Mer information om hur du arbetar med Program.csfinns i Start-up and configuration in the isolated worker model guide (Start-up and configuration in the isolated worker model guide).

Standardexemplen Program.cs ovan är installation av Application Insights-integrering för den isolerade arbetsmodellen. I måste Program.csdu även konfigurera loggfiltrering som ska gälla för loggar som kommer från kod i projektet. I den isolerade arbetsmodellen host.json styr filen endast händelser som genereras av Functions-värdkörningen. Om du inte konfigurerar filtreringsregler i Program.cskan 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, bör du tänka på att dessa på samma sätt endast gäller för kod i projektet. Utlösar- och bindningskonfiguration krävs också av plattformen, 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 också 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 bara utföra en strängersättning i projektet.

Loggning

I den processbaserade modellen kan du inkludera en valfri ILogger parameter i funktionen, 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 beroendeinmatning för att hämta 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 ska å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 "Input" läggas till i deras namn. Om du till exempel använde indatabindningsattributet CosmosDB i inprocessmodellen skulle attributet nu vara CosmosDBInput.
   • Utdatabindningar behöver vanligtvis "Output" 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 bara 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 din local.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 i host.json filen. Men om Application Insights-konfigurationen i den här filen från ditt processmodellprojekt kanske du vill göra ytterligare ändringar i Program.cs filen. Filen host.json styr endast loggning från Functions-värdkörningen, och i den isolerade arbetsmodellen 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 System.Text.Json den isolerade arbetsmodellen för JSON-serialisering. Om du vill anpassa serialiseraralternativ eller växla till JSON.NET (Newtonsoft.Json) kan du läsa de här anvisningarna.

Application Insights-loggnivåer och filtrering

Loggar kan skickas till Application Insights från både Functions-värdkörningen och koden i projektet. Gör host.json att du kan konfigurera regler för värdloggning, men för att styra loggar som kommer från din kod 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"]}!");
        }
    }
}

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

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 produktionsplatsen via en växlingsåtgärd.

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

1. Skapa ett distributionsfack 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 även 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 anvisningarna för att uppdatera stackkonfigurationen för den isolerade arbetsmodellen. Du kommer att använda samma instruktioner för eventuella framtida .NET-versionsuppdateringar som du gör.

   Om du har någon automatiserad infrastrukturetablering, till dotnet-isolated exempel en CI/CD-pipeline, kontrollerar du att automatiseringarna också uppdateras för att hålla FUNCTIONS_WORKER_RUNTIME inställt på och för att rikta 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 ä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-produktionsplatsen) under interimstillståndet.

4. Bekräfta att programmet fungerar som förväntat inom mellanlagringsplatsen (icke-produktion).

5. Utför en växlingsåtgärd för fack. Detta tillämpar de ändringar som du har gjort i mellanlagringsplatsen (icke-produktion) på produktionsplatsen. Ett fackbyte sker som en enskild uppdatering, vilket undviker att införa interimfeltillståndet i produktionsmiljön.

6. Bekräfta att programmet fungerar som förväntat inom produktionsplatsen.

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