Migrowanie aplikacji platformy .NET z modelu procesu do izolowanego modelu procesu roboczego

  • Artykuł

Ważne

Wsparcie zostanie zakończone dla modelu procesu 10 listopada 2026 r. Zdecydowanie zalecamy przeprowadzenie migracji aplikacji do izolowanego modelu procesu roboczego, postępując zgodnie z instrukcjami w tym artykule.

Ten artykuł przeprowadzi Cię przez proces bezpiecznego migrowania aplikacji funkcji platformy .NET z modelu procesu do izolowanego modelu procesu roboczego. Aby dowiedzieć się więcej o różnicach wysokiego poziomu między tymi modelami, zobacz porównanie trybu wykonywania.

W tym przewodniku założono, że aplikacja działa w wersji 4.x środowiska uruchomieniowego usługi Functions. Jeśli nie, należy zamiast tego postępować zgodnie z przewodnikami dotyczącymi uaktualniania wersji hosta:

Te przewodniki migracji wersji hosta ułatwią również migrację do izolowanego modelu procesu roboczego podczas ich pracy.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu programu Azure PowerShell, aby wygenerować listę aplikacji funkcji w ramach subskrypcji, które obecnie korzystają z modelu przetwarzania.

Skrypt używa subskrypcji, z którą program Azure PowerShell jest obecnie skonfigurowany do użycia. Subskrypcję można zmienić, uruchamiając Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' polecenie i zastępując <YOUR SUBSCRIPTION ID> element identyfikatorem subskrypcji, którą chcesz ocenić.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Wybierz docelową wersję platformy .NET

W wersji 4.x środowiska uruchomieniowego usługi Functions aplikacja funkcji platformy .NET jest przeznaczona dla platformy .NET 6 podczas korzystania z modelu w procesie.

Podczas migracji aplikacji funkcji możesz wybrać docelową wersję platformy .NET. Projekt języka C# można zaktualizować do jednej z następujących wersji platformy .NET obsługiwanych przez usługę Functions w wersji 4.x:

Wersja platformy .NET Typ wydania oficjalnych zasad pomocy technicznej platformy .NET Modelprzetwarzania funkcji 1,3
.NET 82 LTS Model izolowanego procesu roboczego
.NET 7 STS (koniec wsparcia 14 maja 2024 r.) Model izolowanego procesu roboczego
.NET 6 LTS (koniec wsparcia 12 listopada 2024 r.) Model izolowanego procesu roboczego,
Modelw procesie 3
.NET Framework 4.8 Zobacz zasady Model izolowanego procesu roboczego

1 Model izolowanego procesu roboczego obsługuje wersje platformy .NET (Long Term Support) i Standard Term Support (STS) oraz .NET Framework. Model w procesie obsługuje tylko wersje LTS platformy .NET. Aby zapoznać się z pełnym porównaniem funkcji i funkcjonalności między dwoma modelami, zobacz Różnice między procesem procesowym i izolowanym procesem roboczym .NET Azure Functions.

Wersja 2 .NET 8 nie jest jeszcze obsługiwana w modelu przetwarzania, chociaż jest dostępna w modelu izolowanego procesu roboczego. Aby uzyskać informacje na temat planów platformy .NET 8, w tym przyszłych opcji modelu przetwarzania, zobacz wpis Aktualizacja planu działania usługi Azure Functions.

3 Wsparcie kończy się dla modelu procesu 10 listopada 2026 r. Aby uzyskać więcej informacji, zobacz to ogłoszenie pomocy technicznej. Aby zapewnić ciągłą pełną obsługę, należy przeprowadzić migrację aplikacji do izolowanego modelu procesu roboczego.

Napiwek

Zalecamy uaktualnienie do platformy .NET 8 w modelu izolowanego procesu roboczego. Zapewnia to szybką ścieżkę migracji do w pełni wydanej wersji z najdłuższym oknem pomocy technicznej platformy .NET.

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 7 lub .NET 6. Jeśli chcesz kierować te wersje, możesz dostosować przykłady platformy .NET 8.

Przygotowanie do migracji

Jeśli jeszcze tego nie zrobiono, zidentyfikuj listę aplikacji, które muszą zostać zmigrowane w bieżącej subskrypcji platformy Azure przy użyciu programu Azure PowerShell.

Przed przeprowadzeniem migracji aplikacji do izolowanego modelu procesu roboczego należy dokładnie przejrzeć zawartość tego przewodnika i zapoznać się z funkcjami izolowanego modelu procesu roboczego oraz różnicami między dwoma modelami.

Aby przeprowadzić migrację aplikacji, wykonasz następujące elementy:

  1. Wykonaj kroki opisane w artykule Migrowanie projektu lokalnego, aby przeprowadzić migrację projektu lokalnego do izolowanego modelu procesu roboczego.
  2. Po przeprowadzeniu migracji projektu w pełni przetestuj aplikację lokalnie przy użyciu wersji 4.x narzędzi Azure Functions Core Tools.
  3. Zaktualizuj aplikację funkcji na platformie Azure do modelu izolowanego.

Migrowanie projektu lokalnego

W sekcji opisano różne zmiany, które należy wprowadzić w projekcie lokalnym, aby przenieść go do izolowanego modelu procesu roboczego. Niektóre kroki zmieniają się w oparciu o docelową wersję platformy .NET. Użyj kart, aby wybrać instrukcje pasujące do żądanej wersji. W tych krokach przyjęto założenie lokalnego projektu języka C#, a jeśli aplikacja używa skryptu języka C# (.csx plików), przed kontynuowaniem należy przekonwertować go na model projektu.

Napiwek

Jeśli przechodzisz do wersji LTS lub STS platformy .NET, asystent uaktualniania platformy .NET może służyć do automatycznego wprowadzania wielu zmian wymienionych w poniższych sekcjach.

Najpierw przekonwertujesz plik projektu i zaktualizujesz zależności. Jak to zrobisz, zobaczysz błędy kompilacji dla projektu. W kolejnych krokach wprowadzisz odpowiednie zmiany, aby usunąć te błędy.

Plik projektu

Poniższy przykład to .csproj plik projektu, który używa platformy .NET 6 w wersji 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>

Użyj jednej z następujących procedur, aby zaktualizować ten plik XML do uruchomienia w izolowanym modelu procesu roboczego:

W tych krokach przyjęto założenie lokalnego projektu języka C#, a jeśli aplikacja używa skryptu języka C# (.csx plików), przed kontynuowaniem należy przekonwertować go na model projektu.

W pliku projektu XML wymagane .csproj są następujące zmiany:

  1. Ustaw wartość PropertyGroup.TargetFramework do net8.0.

  2. Ustaw wartość PropertyGroup.AzureFunctionsVersion do v4.

  3. Dodaj następujący OutputType element do elementu PropertyGroup:

    <OutputType>Exe</OutputType>

  4. W pliku ItemGroup.PackageReference lista, zastąp odwołanie Microsoft.NET.Sdk.Functions do pakietu następującymi odwołaniami:

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

    Zanotuj wszystkie odwołania do innych pakietów w Microsoft.Azure.WebJobs.* przestrzeniach nazw. Te pakiety zostaną zastąpione w późniejszym kroku.

  5. Dodaj następujący nowy ItemGroupelement :

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

Po wprowadzeniu tych zmian zaktualizowany projekt powinien wyglądać podobnie do następującego przykładu:

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

Odwołania do pakietu

Podczas migracji do izolowanego modelu roboczego należy zmienić pakiety odwołań aplikacji.

Jeśli jeszcze tego nie zrobiono, zaktualizuj projekt, aby odwoływać się do najnowszych stabilnych wersji:

W zależności od wyzwalaczy i powiązań używanych przez aplikację może być konieczne odwołanie do innego zestawu pakietów. W poniższej tabeli przedstawiono zamiany niektórych najczęściej używanych rozszerzeń:

Scenariusz Zmiany odwołań do pakietu
Wyzwalacz czasomierza Dodaj
Microsoft.Azure.Functions.Worker.Extensions.Timer
Powiązania magazynu Replace
Microsoft.Azure.WebJobs.Extensions.Storage
with
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues i
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania obiektu blob Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Powiązania kolejki Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Powiązania tabeli Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Tables
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania usługi Cosmos DB Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
i/lub
Microsoft.Azure.WebJobs.Extensions.DocumentDB
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Powiązania usługi Service Bus Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Powiązania usługi Event Hubs Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventHubs
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Powiązania usługi Event Grid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventGrid
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Powiązania usługi SignalR Service Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SignalRService
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Trwałe funkcje Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Trwałe funkcje
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Trwałe funkcje
(Dostawca magazynu Netherite)		 Zamień odwołania na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Powiązania usługi SendGrid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SendGrid
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Powiązania platformy Kafka Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Kafka
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Powiązania RabbitMQ Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Wstrzykiwanie zależności
i konfiguracja uruchamiania		 Usuń odwołania do
Microsoft.Azure.Functions.Extensions
(Model izolowanego procesu roboczego domyślnie udostępnia tę funkcję).

Zobacz Obsługiwane powiązania , aby zapoznać się z pełną listą rozszerzeń, które należy wziąć pod uwagę, i zapoznaj się z dokumentacją każdego rozszerzenia, aby uzyskać pełne instrukcje instalacji dla izolowanego modelu procesów. Pamiętaj, aby zainstalować najnowszą stabilną wersję wszystkich docelowych pakietów.

Napiwek

Wszelkie zmiany w wersjach rozszerzeń w trakcie tego procesu mogą wymagać również zaktualizowania host.json pliku. Pamiętaj, aby zapoznać się z dokumentacją każdego używanego rozszerzenia. Na przykład rozszerzenie usługi Service Bus ma zmiany powodujące niezgodność w strukturze między wersjami 4.x i 5.x. Aby uzyskać więcej informacji, zobacz Powiązania usługi Azure Service Bus dla usługi Azure Functions.

Aplikacja modelu izolowanego procesu roboczego nie powinna odwoływać się do żadnych pakietów w Microsoft.Azure.WebJobs.* przestrzeniach nazw ani Microsoft.Azure.Functions.Extensions. Jeśli masz jakiekolwiek pozostałe odwołania do tych odwołań, należy je usunąć.

Napiwek

Aplikacja może również zależeć od typów zestawu Azure SDK w ramach wyzwalaczy i powiązań lub jako zależności autonomicznej. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń usługi Functions współdziałają z najnowszymi wersjami zestawu Azure SDK dla platformy .NET, prawie wszystkich pakietów, dla których jest formularz Azure.*.

plik Program.cs

Podczas migracji do uruchomienia w izolowanym procesie roboczym należy dodać Program.cs plik do projektu z następującą zawartością:

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

Ten przykład obejmuje integrację ASP.NET Core w celu zwiększenia wydajności i udostępnienia znanego modelu programowania, gdy aplikacja używa wyzwalaczy HTTP. Jeśli nie zamierzasz używać wyzwalaczy HTTP, możesz zastąpić wywołanie ConfigureFunctionsWebApplication metody wywołaniem metody ConfigureFunctionsWorkerDefaults. Jeśli to zrobisz, możesz usunąć odwołanie z Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore pliku projektu. Jednak aby uzyskać najlepszą wydajność, nawet w przypadku funkcji z innymi typami wyzwalaczy, należy zachować FrameworkReference wartość na ASP.NET Core.

Plik Program.cs zastąpi dowolny plik, który ma FunctionsStartup atrybut , który jest zazwyczaj plikiem Startup.cs . W miejscach, w których FunctionsStartup kod będzie się odwoływaćIFunctionsHostBuilder.Services, można zamiast tego dodać instrukcje w .ConfigureServices() metodzie HostBuilder w pliku .Program.cs Aby dowiedzieć się więcej na temat pracy z Program.csprogramem , zobacz Start-up and configuration (Uruchamianie i konfigurowanie ) w przewodniku po izolowanym modelu procesu roboczego.

Powyższe przykłady domyślne Program.cs obejmują konfigurację integracji aplikacji Szczegółowe informacje dla izolowanego modelu procesu roboczego. W programie Program.csnależy również skonfigurować filtrowanie dzienników, które ma być stosowane do dzienników pochodzących z kodu w projekcie. W modelu host.json izolowanego procesu roboczego plik kontroluje tylko zdarzenia emitowane przez środowisko uruchomieniowe hosta usługi Functions. Jeśli nie skonfigurujesz reguł filtrowania w programie Program.cs, mogą pojawić się różnice w poziomach dziennika obecnych dla różnych kategorii w telemetrii.

Chociaż można zarejestrować niestandardowe źródła konfiguracji w ramach programu HostBuilder, należy pamiętać, że mają one zastosowanie tylko do kodu w projekcie. Konfiguracja wyzwalacza i powiązania jest również wymagana przez platformę i powinna zostać udostępniona za pośrednictwem ustawień aplikacji, odwołań do usługi Key Vault lub funkcji odwołań do usługi App Configuration.

Po przeniesieniu wszystkiego z dowolnego istniejącego FunctionsStartupProgram.cs do pliku można usunąć FunctionsStartup atrybut i klasę, do której został zastosowany.

Zmiany podpisu funkcji

Niektóre typy kluczy zmieniają się między modelem procesu a izolowanym modelem procesu roboczego. Wiele z nich odnosi się do atrybutów, parametrów i zwracanych typów tworzących sygnaturę funkcji. Dla każdej funkcji należy wprowadzić zmiany w następujących celach:

  • Atrybut funkcji (który również ustawia nazwę funkcji)
  • Jak funkcja uzyskuje element ILogger/ILogger<T>
  • Wyzwalanie i wiązanie atrybutów i parametrów

Pozostała część tej sekcji przeprowadzi Cię przez poszczególne z tych kroków.

Atrybuty funkcji

Atrybut FunctionName jest zastępowany przez Function atrybut w izolowanym modelu procesu roboczego. Nowy atrybut ma ten sam podpis, a jedyną różnicą jest nazwa. W związku z tym można po prostu wykonać zamianę ciągu w projekcie.

Rejestrowanie

W modelu przetwarzania można dołączyć dodatkowy ILogger parametr do funkcji lub użyć iniekcji zależności, aby uzyskać element ILogger<T>. Jeśli używasz już wstrzykiwania zależności, te same mechanizmy działają w modelu izolowanego procesu roboczego.

Jednak w przypadku wszystkich funkcji, które opierały się na parametrze ILogger metody, należy wprowadzić zmianę. Zaleca się użycie wstrzykiwania zależności w celu uzyskania klasy ILogger<T>. Wykonaj następujące kroki, aby przeprowadzić migrację mechanizmu rejestrowania funkcji:

  1. W klasie funkcji dodaj private readonly ILogger<MyFunction> _logger; właściwość, zastępując MyFunction ciąg nazwą klasy funkcji.

  2. Utwórz konstruktor dla klasy funkcji, który przyjmuje ILogger<T> parametr jako parametr:

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

    Zastąp oba wystąpienia MyFunction w powyższym fragmencie kodu nazwą klasy funkcji.

  3. W przypadku operacji rejestrowania w kodzie funkcji zastąp odwołania do parametru parametrem ILogger_logger.

  4. ILogger Usuń parametr z sygnatury funkcji.

Aby dowiedzieć się więcej, zobacz Rejestrowanie w modelu izolowanego procesu roboczego.

Wyzwalanie i wiązanie zmian

Po zmianie odwołań do pakietu w poprzednim kroku wprowadzono błędy dla wyzwalaczy i powiązań, które zostaną rozwiązane:

  1. Usuń wszystkie using Microsoft.Azure.WebJobs; instrukcje.

  2. Dodaj instrukcję using Microsoft.Azure.Functions.Worker; .

  3. Dla każdego atrybutu powiązania zmień nazwę atrybutu zgodnie z opisem w dokumentacji referencyjnej, którą można znaleźć w indeksie Obsługiwane powiązania . Ogólnie rzecz biorąc, nazwy atrybutów zmieniają się w następujący sposób:

    • Wyzwalacze zwykle pozostają nazwane w taki sam sposób. Na przykład QueueTrigger to nazwa atrybutu dla obu modeli.
    • Powiązania wejściowe zwykle wymagają dodania wartości "Input" do ich nazwy. Jeśli na przykład użyto atrybutu powiązania wejściowego CosmosDB w modelu przetwarzania, będzie to teraz .CosmosDBInput
    • Powiązania wyjściowe zwykle wymagają dodania wartości "Output" do ich nazwy. Jeśli na przykład użyto atrybutu powiązania wyjściowego Queue w modelu przetwarzania, będzie to teraz .QueueOutput

  4. Zaktualizuj parametry atrybutu, aby odzwierciedlały izolowane wersje modelu procesu roboczego, jak określono w dokumentacji referencyjnej powiązania.

    Na przykład w modelu przetwarzania powiązanie wyjściowe obiektu blob jest reprezentowane przez [Blob(...)] atrybut zawierający Access właściwość. W modelu izolowanego procesu roboczego atrybut wyjściowy obiektu blob to [BlobOutput(...)]. Powiązanie nie wymaga Access już właściwości, aby można było usunąć ten parametr. Więc [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] stałby się .[BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]

  5. Przenieś powiązania wyjściowe z listy parametrów funkcji. Jeśli masz tylko jedno powiązanie wyjściowe, możesz zastosować je do zwracanego typu funkcji. Jeśli masz wiele danych wyjściowych, utwórz nową klasę z właściwościami dla poszczególnych danych wyjściowych i zastosuj atrybuty do tych właściwości. Aby dowiedzieć się więcej, zobacz Wiele powiązań wyjściowych.

  6. Zapoznaj się z dokumentacją referencyjną każdego powiązania dla typów, z których można powiązać. W niektórych przypadkach może być konieczne zmianę typu. W przypadku powiązań wyjściowych, jeśli wersja modelu w procesie używa elementu IAsyncCollector<T>, można zastąpić to powiązaniem do tablicy typu docelowego: T[]. Można również rozważyć zastąpienie powiązania wyjściowego obiektem klienta dla usługi, którą reprezentuje, jako typ powiązania dla powiązania wejściowego, jeśli jest dostępne, lub przez samodzielne wstrzyknięcie klienta.

  7. Jeśli funkcja zawiera IBinder parametr, usuń go. Zastąp funkcję obiektem klienta usługi, który reprezentuje, jako typ powiązania dla powiązania wejściowego, jeśli jest dostępny, lub przez samodzielne wstrzyknięcie klienta.

  8. Zaktualizuj kod funkcji, aby pracować z dowolnymi nowymi typami.

plik local.settings.json

Plik local.settings.json jest używany tylko w przypadku uruchamiania lokalnego. Aby uzyskać informacje, zobacz Plik ustawień lokalnych.

Podczas migracji z uruchamiania procesu w procesie wyizolowanego procesu roboczego należy zmienić FUNCTIONS_WORKER_RUNTIME wartość na "dotnet-isolated". Upewnij się, że plik local.settings.json zawiera co najmniej następujące elementy:

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

Wartość skonfigurowana dla polecenia "AzureWebJobsStorage" może być inna. Nie trzeba zmieniać jej wartości w ramach migracji.

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jeśli jednak konfiguracja aplikacji Szczegółowe informacje w tym pliku z projektu modelu procesowego, może być konieczne wprowadzenie dodatkowych zmian w Program.cs pliku. Plik host.json steruje tylko rejestrowaniem ze środowiska uruchomieniowego hosta usługi Functions, a w modelu izolowanego procesu roboczego niektóre z tych dzienników pochodzą bezpośrednio z aplikacji, co zapewnia większą kontrolę. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Inne zmiany kodu

W tej sekcji wyróżniono inne zmiany kodu, które należy wziąć pod uwagę podczas pracy z migracją. Te zmiany nie są wymagane przez wszystkie aplikacje, ale należy ocenić, czy istnieją odpowiednie dla Twoich scenariuszy.

Serializacja JSON

Domyślnie izolowany model procesu roboczego jest używany System.Text.Json do serializacji JSON. Aby dostosować opcje serializatora lub przełączyć się na JSON.NET (Newtonsoft.Json), zobacz te instrukcje.

Poziomy i filtrowanie dzienników Szczegółowe informacje aplikacji

Dzienniki można wysyłać do aplikacji Szczegółowe informacje zarówno ze środowiska uruchomieniowego hosta usługi Functions, jak i kodu w projekcie. Umożliwia host.json skonfigurowanie reguł rejestrowania hosta, ale w celu kontrolowania dzienników pochodzących z kodu należy skonfigurować reguły filtrowania w ramach elementu Program.cs. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Przykładowe migracje funkcji

Przykład wyzwalacza HTTP

Wyzwalacz HTTP dla modelu przetwarzania może wyglądać podobnie do następującego przykładu:

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

Wyzwalacz HTTP dla zmigrowanej wersji może wyglądać podobnie do następującego przykładu:

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

Aktualizowanie aplikacji funkcji na platformie Azure

Uaktualnienie aplikacji funkcji do izolowanego modelu składa się z dwóch kroków:

  1. Zmień konfigurację aplikacji funkcji tak, aby korzystała z modelu izolowanego, ustawiając FUNCTIONS_WORKER_RUNTIME ustawienie aplikacji na dotnet-isolated. Upewnij się, że każda automatyzacja wdrażania jest podobnie zaktualizowana.
  2. Opublikuj zmigrowany projekt do zaktualizowanej aplikacji funkcji.

Gdy używasz programu Visual Studio do publikowania izolowanego projektu modelu procesu roboczego w istniejącej aplikacji funkcji korzystającej z modelu przetwarzania, podczas wdrażania zostanie wyświetlony monit o zaktualizowanie aplikacji funkcji programu Visual Studio. Umożliwia to wykonanie obu kroków jednocześnie.

Jeśli musisz zminimalizować przestój, rozważ użycie miejsca przejściowego do przetestowania i zweryfikowania zmigrowanego kodu ze zaktualizowaną konfiguracją na platformie Azure. Następnie możesz wdrożyć w pełni zmigrowany aplikację do miejsca produkcyjnego za pomocą operacji zamiany.

Po wykonaniu tych kroków aplikacja została w pełni zmigrowana do izolowanego modelu. Gratulacje! Powtórz kroki opisane w tym przewodniku w razie potrzeby w przypadku innych aplikacji wymagających migracji.

Następne kroki

Dowiedz się więcej o izolowanym modelu procesu roboczego