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

Viktigt!

Supporten upphör för den pågående modellen 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ö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 igenom 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:

.NET-version	Versionstyp för .NET Official Support Policy	Funktionsprocessmodell1,3
.NET 82	LTS	Isolerad arbetsmodell
.NET 7	STS (support upphör 14 maj 2024)	Isolerad arbetsmodell
.NET 6	LTS (support upphör 12 november 2024)	Isolerad arbetsmodell, Processmodell3
.NET Framework 4.8	Se princip	Isolerad arbetsmodell

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

² .NET 8 stöds ännu inte i den pågående modellen, även om den är tillgänglig för den isolerade arbetsmodellen. Information om .NET 8-planer, inklusive framtida alternativ för den processbaserade modellen, finns i Azure Functions-översiktsuppdateringsposten.

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

Dricks

Vi rekommenderar att du uppgraderar till .NET 8 på den isolerade arbetsmodellen. Detta ger en snabb migreringssökväg till den fullständigt släppta versionen med det längsta supportfönstret från .NET.

Den här guiden innehåller inte några specifika exempel för .NET 7 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 och 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. Slutför stegen i Migrera ditt lokala projekt för att migrera ditt lokala projekt till den isolerade arbetsmodellen.
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.

Dricks

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.

Först ska du konvertera 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:

.NET 8

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.

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

1. Ange värdet PropertyGroupför .TargetFramework till net8.0.

2. Ange värdet PropertyGroupför .AzureFunctionsVersion till v4.

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

   <OutputType>Exe</OutputType>
   

4. ItemGroupI .PackageReference ersätter du paketreferensen till 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>

.NET Framework 4.8

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.

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

1. Ange värdet PropertyGroupför .TargetFramework till net48.

2. Ange värdet PropertyGroupför .AzureFunctionsVersion till v4.

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

   <OutputType>Exe</OutputType>
   

4. ItemGroupI .PackageReference ersätter du paketreferensen till Microsoft.NET.Sdk.Functions med följande referenser:

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

   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>
     <Folder Include="Properties\" />
   </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>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>

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:

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 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
Event Grid-bindningar	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
Bestående funktioner	Ersätt referenser till Microsoft.Azure.WebJobs.Extensions.DurableTask med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Bestående funktioner (SQL-lagringsprovider)	Ersätt referenser till Microsoft.DurableTask.SqlServer.AzureFunctions med den senaste versionen av Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Bestående 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
Beroendeinmatning 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å.

Dricks

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 paket som är formuläret 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:

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

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.

.NET Framework 4.8

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 FunctionName ersätts av Function attributet i den isolerade arbetsmodellen. 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 ytterligare en ILogger parameter i funktionen, eller så kan du använda beroendeinmatning för att hämta en ILogger<T>. Om du redan använde 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 kodfragmentet ovan 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 detta nu vara CosmosDBInput.
   • Utdatabindningar behöver vanligtvis "Output" läggas till i namnet. Om du till exempel använde utdatabindningsattributet Queue i den processbaserade modellen skulle detta 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"
    }
}

Det värde som du har konfigurerat 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 kanske gillar följande exempel:

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

.NET Framework 4.8

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

Uppgraderingen av funktionsappen till den isolerade modellen består av två steg:

1. Ändra konfigurationen av funktionsappen så att den använder den isolerade modellen genom att ange programinställningen FUNCTIONS_WORKER_RUNTIME till dotnet-isolated. Kontrollera att all distributionsautomatisering uppdateras på samma sätt.
2. Publicera ditt migrerade projekt till den uppdaterade funktionsappen.

När du använder Visual Studio för att publicera ett isolerat arbetsmodellprojekt till en befintlig funktionsapp som använder den pågående modellen uppmanas du att låta Visual Studio uppdatera funktionsappen under distributionen. Detta åstadkommer båda stegen samtidigt.

Om du behöver minimera stilleståndstiden bör du överväga att använda ett mellanlagringsfack för att 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.

När du har slutfört de här stegen har appen migrerats helt till 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