Udostępnij za pośrednictwem

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łatwiają 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 lub .NET 8 podczas korzystania z modelu przetwarzania.

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,2
.NET 9 STS (koniec wsparcia 12 maja 2026 r.) Model izolowanego procesu roboczego
.NET 8 LTS (koniec wsparcia 10 listopada 2026 r.) Model izolowanego procesu roboczego,
Modelw procesie 2
.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, kończące się na platformie .NET 8. 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.

2 Zakończenie wsparcia 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 9. Jeśli musisz kierować się do tej wersji, 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. Należy również zapoznać się z funkcjami izolowanego modelu roboczego oraz różnicami między dwoma modelami.

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

  1. Przeprowadź migrację projektu lokalnego do izolowanego modelu procesu roboczego, wykonując kroki opisane w artykule Migrowanie projektu lokalnego.
  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 przekonwertuj plik projektu i zaktualizuj 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 8 w wersji 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>

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>

Zmiana struktury docelowej projektu może również wymagać zmian w częściach łańcucha narzędzi poza kodem projektu. Na przykład w programie VS Code może być konieczne zaktualizowanie azureFunctions.deploySubpath ustawienia rozszerzenia za pomocą ustawień użytkownika lub pliku projektu .vscode/settings.json . Sprawdź, czy nie ma zależności od wersji struktury, która może istnieć poza kodem projektu, w ramach kroków kompilacji lub potoku ciągłej integracji/ciągłego wdrażania.

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 domyślne Program.cs przykłady obejmują konfigurację integracji usługi Application Insights 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 FunctionsStartup Program.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

W pozostałej części tej sekcji przedstawiono poszczególne kroki.

Atrybuty funkcji

Atrybut Function w izolowanym modelu procesu roboczego zastępuje FunctionName atrybut . 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ć opcjonalny ILogger parametr do funkcji lub użyć iniekcji zależności, aby uzyskać element ILogger<T>. Jeśli aplikacja już używała wstrzykiwania zależności, te same mechanizmy działają w izolowanym modelu 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 poprzednim 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, atrybut będzie 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, ten atrybut będzie 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ść dla elementu "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 usługi Application Insights w tym pliku z projektu modelu przetwarzania może być konieczna, aby wprowadzić dodatkowe zmiany 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 dzienników i filtrowanie usługi Application Insights

Dzienniki można wysyłać do usługi Application Insights 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

Zaktualizowanie aplikacji funkcji do izolowanego modelu obejmuje dwie zmiany, które należy wykonać razem, ponieważ w przypadku ukończenia tylko jednego aplikacja jest w stanie błędu. Obie te zmiany powodują również ponowne uruchomienie procesu aplikacji. Z tych powodów należy przeprowadzić aktualizację przy użyciu miejsca przejściowego. Miejsca przejściowe pomagają zminimalizować przestoje aplikacji i umożliwić testowanie i weryfikowanie zmigrowanego kodu przy użyciu zaktualizowanej konfiguracji na platformie Azure. Następnie możesz wdrożyć w pełni zmigrowany aplikację do miejsca produkcyjnego za pomocą operacji zamiany.

Ważne

Gdy wdrożony ładunek aplikacji nie jest zgodny ze skonfigurowanym środowiskiem uruchomieniowym, będzie on w stanie błędu. Podczas procesu migracji aplikacja zostanie umieszczona w tym stanie, najlepiej tylko tymczasowo. Miejsca wdrożenia pomagają wyeliminować wpływ tego błędu, ponieważ stan błędu zostanie rozwiązany w środowisku przejściowym (nieprodukcyjnym), zanim zmiany zostaną zastosowane jako pojedyncza aktualizacja środowiska produkcyjnego. Miejsca również bronią przed wszelkimi błędami i umożliwiają wykrywanie innych problemów przed dotarciem do środowiska produkcyjnego.

W trakcie tego procesu mogą nadal występować błędy w dziennikach pochodzących z miejsca przejściowego (nieprodukcyjnego). Jest to oczekiwane, choć powinny one odejść w miarę przechodzenia przez kroki. Przed wykonaniem operacji zamiany miejsca należy potwierdzić, że te błędy przestaną być zgłaszane i że aplikacja działa zgodnie z oczekiwaniami.

Wykonaj następujące kroki, aby użyć miejsc wdrożenia w celu zaktualizowania aplikacji funkcji do izolowanego modelu procesu roboczego:

  1. Utwórz miejsce wdrożenia, jeśli jeszcze tego nie zrobiono. Możesz również zapoznać się z procesem zamiany miejsca i upewnić się, że możesz wprowadzać aktualizacje do istniejącej aplikacji z minimalnymi zakłóceniami.

  2. Zmień konfigurację miejsca przejściowego (nieprodukcyjnego), aby używać modelu izolowanego procesu roboczego, ustawiając FUNCTIONS_WORKER_RUNTIME ustawienie aplikacji na dotnet-isolated. FUNCTIONS_WORKER_RUNTIMEnie powinny być oznaczone jako "ustawienie miejsca".

    Jeśli w ramach aktualizacji jest również przeznaczona inna wersja platformy .NET, należy również zmienić konfigurację stosu. Aby to zrobić, zobacz instrukcje dotyczące aktualizowania konfiguracji stosu dla izolowanego modelu procesu roboczego. Te same instrukcje będą używane w przypadku wszelkich przyszłych aktualizacji wersji platformy .NET, które zostaną utworzone.

    Jeśli masz dowolną automatyczną aprowizację infrastruktury, taką jak potok ciągłej integracji/ciągłego wdrażania, upewnij się, że automatyzacje są również aktualizowane, aby zachować FUNCTIONS_WORKER_RUNTIME ustawienie i dotnet-isolated wybrać prawidłową wersję platformy .NET.

  3. Opublikuj zmigrowany projekt w miejscu przejściowym (nieprodukcyjnym) aplikacji funkcji.

    Jeśli używasz programu Visual Studio do publikowania izolowanego projektu modelu procesu roboczego w istniejącej aplikacji lub miejscu używającym modelu przetwarzania, może on również wykonać poprzedni krok w tym samym czasie. Jeśli poprzedni krok nie został ukończony, program Visual Studio wyświetli monit o zaktualizowanie aplikacji funkcji podczas wdrażania. Program Visual Studio przedstawia to jako jedną operację, ale nadal są to dwie oddzielne operacje. W dziennikach mogą nadal występować błędy z miejsca przejściowego (nieprodukcyjnego) w stanie przejściowym.

  4. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w miejscu przejściowym (nieprodukcyjnym).

  5. Wykonaj operację zamiany miejsca. Dotyczy to zmian wprowadzonych w miejscu przejściowym (nieprodukcyjnym) do miejsca produkcyjnego. Zamiana miejsca odbywa się jako pojedyncza aktualizacja, która pozwala uniknąć wprowadzania stanu błędu tymczasowego w środowisku produkcyjnym.

  6. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w miejscu produkcyjnym.

Po wykonaniu tych kroków migracja zostanie ukończona, a aplikacja zostanie uruchomiona w modelu izolowanym. 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