Migrowanie aplikacji z Azure Functions w wersji 3.x do wersji 4.x

Ważne

Od 13 grudnia 2022 r. aplikacje funkcji działające w wersjach 2.x i 3.x środowiska uruchomieniowego Azure Functions osiągnęły koniec rozszerzonej pomocy technicznej. Aby uzyskać więcej informacji, zobacz Wycofane wersje.

Azure Functions w wersji 4.x jest wysoce wstecznie zgodny z wersją 3.x. Większość aplikacji powinna bezpiecznie migrować do wersji 4.x bez konieczności wprowadzania znaczących zmian w kodzie. Aby uzyskać więcej informacji na temat wersji środowiska uruchomieniowego usługi Functions, zobacz Azure Functions wersje środowiska uruchomieniowego — omówienie.

Ważne

Aplikacje funkcjonalne, które nadal uruchamiają wycofane z użytku środowisko uruchomieniowe w wersji 3 w systemie Linux w planie konsumpcyjnym, przestaną działać po 30 września 2026 r. Aby uniknąć przerw w działaniu usługi, przeprowadź migrację aplikacji do środowiska uruchomieniowego w wersji 4.

Opcja hostowania aplikacji funkcji w systemie Linux w planie konsumpcyjnym zostanie wycofana 30 września 2028 r. Plan Konsumpcji systemu Linux nie będzie otrzymywał nowych funkcji ani wersji językowych. Aplikacje działające na Windows w planie Zużycie nie mają obecnie wpływu. Przeprowadź migrację aplikacji do planu Flex Consumption przed datą wycofania.

Ten artykuł przeprowadzi Cię przez proces bezpiecznego migrowania aplikacji funkcji do uruchamiania w wersji 4.x środowiska uruchomieniowego usługi Functions. Ponieważ instrukcje migracji projektu są zależne od języka, pamiętaj, aby wybrać język programowania z selektora w górnej części artykułu.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu programu PowerShell, aby wygenerować listę aplikacji funkcji w subskrypcji, które są obecnie przeznaczone dla wersji 2.x lub 3.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 
 
Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Wybierz docelową wersję .NET

W wersji 3.x środowiska uruchomieniowego usługi Functions aplikacja funkcji języka C# jest przeznaczona dla .NET Core 3.1 przy użyciu modelu w procesie lub .NET 5 przy użyciu izolowanego modelu procesu roboczego.

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

wersja .NET .NET oficjalne zasady wsparcia technicznego typ wydania Modelprzetwarzania funkcji 1,2
.NET 10 LTS (koniec wsparcia technicznego 14 listopada 2028 r.) Model izolowanego procesu roboczego
.NET 9 STS (koniec wsparcia 10 listopada 2026 r.)3 Model izolowanego procesu roboczego
.NET 8 LTS (koniec wsparcia 10 listopada 2026 r.) Model izolowanego pracownika
Model procesowy2
.NET Framework 4.8 Zobacz zasady Model izolowanego procesu roboczego

1 model odizolowanego pracownika obsługuje wersje .NET Long Term Support (LTS) i Standard Term Support (STS), a także .NET Framework. Model in-process obsługuje tylko wersje LTS .NET, do .NET 8 włącznie. Aby uzyskać pełne porównanie funkcji i funkcji między dwoma modelami, zobacz Differences between in-process and isolate worker process .NET Azure Functions (Izolowanie procesów roboczych .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.

3 .NET 9 wcześniej miał oczekiwaną datę zakończenia wsparcia z dnia 12 maja 2026 r. W oknie usługi .NET 9 zespół .NET rozszerzył wsparcie dla wersji STS do 24 miesięcy, począwszy od .NET 9. Aby uzyskać więcej informacji, zobacz wpis w blogu.

Napiwek

Zalecamy aktualizację do .NET 8 w modelu izolowanego procesu roboczego. .NET 8 to w pełni wydana wersja z najdłuższym oknem pomocy technicznej z .NET.

Mimo że zamiast tego można użyć modelu w procesie, nie zalecamy tego podejścia, jeśli można go uniknąć. Obsługa dla modelu realizowanego procesowo zostanie zakończona 10 listopada 2026 r., dlatego przed tym należy przejść do modelu izolowanego pracownika. Wykonanie tej czynności podczas migracji do wersji 4.x spowoduje zmniejszenie całkowitego nakładu pracy, a izolowany model procesu roboczego zapewni aplikacji dodatkowe korzyści, w tym możliwość łatwiejszego określania docelowych przyszłych wersji .NET. Jeśli przechodzisz na izolowany model pracy, .NET Upgrade Assistant może również obsługiwać wiele niezbędnych zmian kodu.

Ten przewodnik nie przedstawia konkretnych przykładów dla .NET 10 (wersja zapoznawcza) ani .NET 9. Jeśli musisz wybrać jedną z tych wersji, możesz dostosować przykłady z .NET 8.

Przygotowanie do migracji

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

Przed przeprowadzeniem migracji aplikacji do wersji 4.x środowiska uruchomieniowego usługi Functions należy wykonać następujące zadania:

  1. Sprawdź listę zmian wpływających na kompatybilność między wersjami 3.x a 4.x.
  2. Wykonaj kroki opisane w artykule Migrowanie projektu lokalnego, aby przeprowadzić migrację projektu lokalnego do wersji 4.x.
  3. Po przeprowadzeniu migracji projektu w pełni przetestuj aplikację lokalnie przy użyciu wersji 4.x Azure Functions Core Tools.
  4. Uruchom moduł sprawdzania poprawności przed uaktualnieniem w aplikacji hostowanej w Azure i rozwiąż wszelkie zidentyfikowane problemy.
  5. Zaktualizuj aplikację funkcji w Azure do nowej wersji. Jeśli musisz zminimalizować przestój, rozważ użycie staging slot do przetestowania i zweryfikowania zmigrowanej aplikacji w Azure w nowej wersji środowiska uruchomieniowego. Następnie możesz wdrożyć aplikację do środowiska produkcyjnego przy użyciu zaktualizowanych ustawień wersji. Aby uzyskać więcej informacji, zobacz Aktualizowanie przy użyciu dostępnych zasobów.
  6. Opublikuj zmigrowany projekt w zaktualizowanej aplikacji funkcjonalnej.

Jeśli używasz Visual Studio do publikowania projektu w wersji 4.x do istniejącej aplikacji funkcji w niższej wersji, podczas wdrażania Visual Studio wyświetli monit o zaktualizowanie aplikacji funkcji do wersji 4.x. Ta aktualizacja używa tego samego procesu zdefiniowanego w Update without slots.

Migrowanie projektu lokalnego

Instrukcje uaktualniania są zależne od języka. Jeśli język nie jest widoczny, wybierz go z selektora w górnej części artykułu.

Wybierz zakładkę zgodną z docelową wersją .NET i żądanym modelem procesów (wewnętrzny proces lub izolowany proces roboczy).

Napiwek

Jeśli przechodzisz do wersji LTS lub STS .NET przy użyciu modelu izolowanego procesu roboczego, .NET Upgrade Assistant można użyć do automatycznego wprowadzenia wielu zmian wymienionych w poniższych sekcjach.

plik projektu

Poniższy przykład to plik projektu .csproj, który używa .NET Core 3.1 w wersji 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </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 usłudze Functions w wersji 4.x:

W tych krokach przyjęto założenie lokalnego projektu w języku C#; Jeśli aplikacja zamiast tego używa skryptu języka C# (pliki csx ), przed kontynuowaniem należy przekonwertować go na model projektu .

Następujące zmiany są wymagane w pliku projektu .csproj XML:

  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 list, zastąp referencję do pakietu Microsoft.NET.Sdk.Functions następującymi referencjami:

      <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 wszelkie odwołania do innych pakietów w przestrzeniach nazw Microsoft.Azure.WebJobs.*. Te pakiety zostaną zastąpione w późniejszym kroku.

  5. Dodaj następujący nowy element ItemGroup:

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

Zmiany pakietu i przestrzeni nazw

Na podstawie modelu, do którego przeprowadzasz migrację, może być konieczne zaktualizowanie lub zmiana pakietów, do których odnosi się aplikacja. Podczas przyjęcia pakietów docelowych musisz zaktualizować przestrzeń nazw instrukcji using oraz niektóre typy, do których się odwołujesz. Możesz zobaczyć wpływ tych zmian przestrzeni nazw na instrukcje using w przykładach szablonu wyzwalacza HTTP w dalszej części tego artykułu.

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 referencji do pakietu
Wyzwalacz czasomierza Dodaj
Microsoft.Azure. Functions.Worker.Extensions.Timer
Powiązania przechowywania Zamień
Microsoft.Azure.WebJobs.Extensions.Storage
z
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ą oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs
Powiązania kolejki Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Powiązania tabeli Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Tables
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania Cosmos DB Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
i/lub
Microsoft.Azure.WebJobs.Extensions.DocumentDB
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.CosmosDB
Powiązania do usługi Service Bus Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.ServiceBus
Powiązania usługi Event Hubs Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventHubs
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.EventHubs
Powiązania usługi Event Grid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventGrid
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.EventGrid
powiązania usługi SignalR Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SignalRService
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.SignalRService
Durable Functions Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Dostawca magazynu Netherite)		 Zamień odwołania na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.Netherite
Powiązania usługi SendGrid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SendGrid
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.SendGrid
Powiązania platformy Kafka Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Kafka
z najnowszą wersją oprogramowania
Microsoft.Azure. Functions.Worker.Extensions.Kafka
Powiązania RabbitMQ Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
z najnowszą wersją oprogramowania
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 Service Bus ma zmiany wprowadzające niezgodności w strukturze między wersjami 4.x i 5.x. Aby uzyskać więcej informacji, zobacz powiązania usługi Azure Service Bus dla funkcji Azure.

Aplikacja izolowanego modelu roboczego nie powinna odwoływać się do żadnych pakietów w przestrzeniach nazw Microsoft.Azure.WebJobs.* lub 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 Azure SDK, używanych jako część wyzwalaczy i powiązań lub jako niezależna zależność. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń Functions działają z najnowszymi wersjami Azure SDK dla .NET, przy czym prawie wszystkie pakiety mają formę Azure.*.

plik Program.cs

Podczas migracji do uruchomienia w izolowanym procesie roboczym należy dodać następujący plik program.cs do projektu:

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 wywołaniem metody ConfigureFunctionsWorkerDefaults. Jeśli to zrobisz, możesz usunąć odwołanie do Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore z pliku projektu. Jednak aby uzyskać najlepszą wydajność, nawet w przypadku funkcji z innymi typami wyzwalaczy, należy utrzymać FrameworkReference w środowisku ASP.NET Core.

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

Domyślne przykłady Program.cs opisane wcześniej obejmują konfigurację usługi Application Insights. W Program.cs należy również skonfigurować filtrowanie dzienników, które ma dotyczyć dzienników pochodzących z kodu w projekcie. W modelu izolowanego procesu roboczego plik host.json kontroluje tylko zdarzenia emitowane przez środowisko uruchomieniowe hosta usługi Functions. Jeśli nie skonfigurujesz reguł filtrowania w Program.cs, mogą wystąpić różnice w poziomach dziennika dostępnych dla różnych kategorii w twojej telemetrii.

Chociaż można zarejestrować niestandardowe źródła konfiguracji w ramach HostBuilderprogramu , mają one podobnie zastosowanie tylko do kodu w projekcie. Platforma wymaga również konfiguracji wyzwalacza i powiązania, a powinna zostać udostępniona za pośrednictwem ustawień aplikacji, odwołań do Key Vault lub odwołań do konfiguracji aplikacji.

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

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 do wersji 4.x upewnij się, że plik local.settings.json zawiera co najmniej następujące elementy:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Uwaga

Podczas migracji z uruchamiania w procesie wewnętrznym do uruchamiania w wyizolowanym procesie pracownika, należy zmienić wartość FUNCTIONS_WORKER_RUNTIME na "dotnet-isolated".

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jednak jeśli konfiguracja usługi Application Insights w tym pliku pochodzi z projektu modelu przetwarzania, możesz chcieć wprowadzić inne zmiany w pliku Program.cs. 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.

Zmiany nazwy klasy

Niektóre klasy kluczy zmieniły nazwy między wersjami. Te zmiany są spowodowane zmianami w interfejsach API .NET lub różnicami między procesem w toku a izolowanym procesem roboczym. W poniższej tabeli przedstawiono kluczowe klasy .NET używane przez funkcje, które mogą ulec zmianie podczas migracji:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (atrybut) Function (atrybut) Function (atrybut)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (przy użyciu integracji ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (przy użyciu integracji ASP.NET Core)
FunctionsStartup (atrybut) Zamiast tego używa Program.cs Zamiast tego używa Program.cs

Mogą również występować różnice nazw klas w wiązaniach. Aby uzyskać więcej informacji, zobacz artykuły referencyjne dotyczące określonych powiązań.

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. Pamiętaj, aby sprawdzić zmiany powodujące niekompatybilność między wersjami 3.x i 4.x oraz inne zmiany, które mogą być konieczne do wprowadzenia w projekcie.

Serializacja JSON

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

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. host.jsonumożliwia konfigurowanie reguł rejestrowania hostów, ale w celu kontrolowania dzienników pochodzących z kodu należy skonfigurować reguły filtrowania w ramach Program.cs. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Szablon wyzwalacza HTTP

Różnice między procesem wewnętrznym a izolowanym procesem roboczym można zobaczyć w funkcjach wyzwalanych przez protokół HTTP. Szablon wyzwalacza HTTP dla wersji 3.x (w procesie) wygląda następująco:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Szablon wyzwalacza HTTP dla zmigrowanej wersji wygląda następująco:

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

Aby zaktualizować projekt do Azure Functions 4.x:

  1. Zaktualizuj lokalną instalację Azure Functions Core Tools do wersji 4.x.

  2. Zaktualizuj pakiet rozszerzeń Azure Functions aplikacji do wersji 2.x lub nowszej. Aby uzyskać więcej informacji, zobacz Zmiany powodujące niezgodność.

  1. W razie potrzeby przejdź do jednej z wersji Java obsługiwanych w wersji 4.x.

  2. Zaktualizuj plik aplikacji POM.xml, aby zmodyfikować FUNCTIONS_EXTENSION_VERSION ustawienie na ~4, tak jak w poniższym przykładzie:

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. W razie potrzeby przejdź do jednej z wersji Node.js obsługiwanych w wersji 4.x.
  1. Skorzystaj z tej okazji, aby przeprowadzić uaktualnienie do programu PowerShell 7.2, co jest zalecane. Aby uzyskać więcej informacji, zobacz Wersje programu PowerShell.
  1. Jeśli używasz Python 3.6, przejdź do jednej z obsługiwanych wersji.

Uruchamianie modułu sprawdzania poprawności przed uaktualnieniem

Azure Functions udostępnia moduł sprawdzania poprawności przed uaktualnieniem, który ułatwia identyfikowanie potencjalnych problemów podczas migrowania aplikacji funkcji do wersji 4.x. Aby uruchomić moduł sprawdzania poprawności przed uaktualnieniem:

  1. W portalu Azure przejdź do swojej aplikacji funkcji.

  2. Otwórz stronę Diagnozowanie i rozwiązywanie problemów.

  3. W Diagnostyce aplikacji funkcji zacznij wpisywać Functions 4.x Pre-Upgrade Validator, a następnie wybierz ją z listy.

  4. Po zakończeniu walidacji przejrzyj zalecenia i rozwiąż wszelkie problemy w aplikacji. Jeśli musisz wprowadzić zmiany w aplikacji, sprawdź poprawność zmian w wersji 4.x środowiska uruchomieniowego Functions, lokalnie przy użyciu narzędzi Azure Functions Core Tools w wersji 4 lub za pomocą slotu przejściowego.

Zaktualizuj aplikację funkcji w Azure

Przed opublikowaniem zmigrowanego projektu należy zaktualizować środowisko uruchomieniowe hosta aplikacji funkcji w Azure do wersji 4.x. Wersja środowiska uruchomieniowego używana przez hosta usługi Functions jest kontrolowana przez FUNCTIONS_EXTENSION_VERSION ustawienie aplikacji, ale w niektórych przypadkach należy również zaktualizować inne ustawienia. Zmiany kodu i zmiany ustawień aplikacji wymagają ponownego uruchomienia aplikacji funkcji.

Najprostszym sposobem jest zaktualizowanie aplikacji bez slotów i ponowne opublikowanie projektu aplikacji. Możesz również zminimalizować przestój w aplikacji i uprościć wycofywanie, aktualizując przy użyciu slotów.

Aktualizacja bez przedziałów

Najprostszym sposobem aktualizacji do wersji 4.x jest ustawienie FUNCTIONS_EXTENSION_VERSION aplikacji na wartość ~4 w aplikacji funkcji w Azure. Musisz wykonać inną procedurę w miejscu z gniazdami.

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Należy również ustawić inne ustawienie, które różni się między Windows i Linux.

W przypadku uruchamiania w Windows należy również włączyć .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

.NET 6 jest wymagany w przypadku aplikacji funkcji w dowolnym języku działającym w Windows.

W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

Teraz możesz ponownie opublikować projekt aplikacji, który został zmigrowany do uruchomienia w wersji 4.x.

Aktualizowanie przy użyciu slotów

Użycie gniazd wdrożeniowych to dobry sposób na aktualizację aplikacji funkcji do wersji środowiska uruchomieniowego 4.x z wcześniejszej wersji. Korzystając z trybu przejściowego, możesz uruchomić swoją aplikację w nowej wersji środowiska uruchomieniowego i przełączyć się do środowiska produkcyjnego po weryfikacji. Sloty również zapewniają sposób na zminimalizowanie przestojów podczas aktualizacji. Jeśli musisz zminimalizować przestój, wykonaj kroki opisane w temacie Minimalna aktualizacja przestoju.

Po zweryfikowaniu aplikacji w zaktualizowanym slocie, możesz zamienić aplikację i ustawienia nowej wersji na środowisko produkcyjne. Ta zamiana wymaga ustawienia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w slocie produkcyjnym. Sposób dodawania tego ustawienia wpływa na ilość przestojów wymaganych do aktualizacji.

Standardowa aktualizacja

Jeśli aplikacja funkcji z włączoną obsługą miejsca może obsługiwać przestój pełnego ponownego uruchamiania, możesz zaktualizować WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie bezpośrednio w miejscu produkcyjnym. Ponieważ zmiana tego ustawienia bezpośrednio w miejscu produkcyjnym powoduje ponowne uruchomienie, które ma wpływ na dostępność, rozważ wykonanie tej zmiany w czasie ograniczonego ruchu. Następnie możesz zamienić zaktualizowaną wersję ze slotu przejściowego.

Polecenie Update-AzFunctionAppSetting cmdlet programu PowerShell nie obsługuje obecnie miejsc. Musisz użyć Azure CLI lub portalu Azure.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w slocie produkcyjnym.

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME>

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów. To polecenie powoduje ponowne uruchomienie aplikacji w miejscu produkcyjnym.

  2. Użyj następującego polecenia, aby również ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  3. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  4. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga .NET 6 w Windows. W systemie Linux aplikacje .NET muszą również zostać zaktualizowane do .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane w .NET 6:

    W przypadku uruchamiania w Windows należy również włączyć .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

    az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 jest wymagany w przypadku aplikacji funkcji w dowolnym języku działającym w Windows.

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  5. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  6. Przed przełączeniem upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  7. Użyj następującego polecenia, aby przenieść aktualizowane gniazdo przejściowe do produkcji:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Aktualizacja minimalizująca przestoje

Aby zminimalizować przestój w aplikacji produkcyjnej, możesz przenieść ustawienia z slotu przejściowego do produkcji. Następnie można wprowadzić zaktualizowaną wersję z wstępnie przygotowanej strefy etapowej.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  2. Użyj następujących poleceń, aby zamienić slot na nowe ustawienie w trybie produkcyjnym, a jednocześnie przywrócić ustawienie wersji w slocie przejściowym.

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    Błędy z lokalnego środowiska testowego mogą wystąpić w czasie między zamianą a przywróceniem wersji środowiska uruchomieniowego dla lokalnego środowiska. Ten błąd może wystąpić, ponieważ gdy WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 występuje tylko w środowisku przejściowym podczas zamiany, usuwane jest ustawienie FUNCTIONS_EXTENSION_VERSION w tym środowisku. Bez ustawienia wersji, twoje gniazdo jest w złym stanie. Aktualizacja wersji w slocie tymczasowym bezpośrednio po zamianie powinna przywrócić slot do właściwego stanu, a w razie potrzeby możesz cofnąć swoje zmiany. Jednak każde wycofanie zamiany wymaga również bezpośredniego usunięcia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 z środowiska produkcyjnego przed przywróceniem zamiany, aby zapobiec wystąpieniu tych samych błędów, które pojawiły się w środowisku przejściowym. Ta zmiana ustawienia produkcyjnego spowoduje ponowne uruchomienie.

  3. Użyj następującego polecenia, aby ponownie ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    W tym momencie oba gniazda mają ustawione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.

  4. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  5. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga .NET 6 w Windows. W systemie Linux aplikacje .NET muszą również zostać zaktualizowane do .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane w .NET 6:

    W przypadku uruchamiania w Windows należy również włączyć .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

    az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 jest wymagany w przypadku aplikacji funkcji w dowolnym języku działającym w Windows.

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  6. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  7. Przed przełączeniem upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  8. Użyj następującego polecenia, aby przełączyć zaktualizowaną i wstępnie podgrzaną szczelinę przejściową na środowisko produkcyjne.

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Przełomowe zmiany między 3.x i 4.x

Poniżej przedstawiono kluczowe zmiany disruptywne, o których należy pamiętać przed uaktualnieniem aplikacji 3.x do wersji 4.x, w tym zmiany specyficzne dla języka. Aby uzyskać pełną listę, zapoznaj się z problemami Azure Functions na GitHubie oznaczonymi etykietą Breaking Change: Approved.

Jeśli język programowania nie jest widoczny, wybierz go w górnej części strony.

Środowisko uruchomieniowe

  • Azure Functions Proxy była funkcją w wersjach od 1.x do 3.x środowiska uruchomieniowego Azure Functions. Ta funkcja nie jest obsługiwana w wersji 4.x. Aby uzyskać więcej informacji, zobacz Bezserwerowe interfejsy API REST przy użyciu Azure Functions.

  • Rejestrowanie do Azure Storage przy użyciu AzureWebJobsDashboard nie jest już obsługiwane od wersji 4.x. Zamiast tego należy użyć usługi Application Insights. (#1923)

  • Azure Functions 4.x wymusza teraz wymagania dotyczące wersji minimum dla rozszerzeń. Zaktualizuj do najnowszej wersji rozszerzeń, których dotyczy problem. W przypadku języków innych niż .NET zaktualizuj pakiet rozszerzeń do wersji 2.x lub nowszej. (#1987)

  • Domyślne i maksymalne limity czasu są teraz egzekwowane w wersji 4.x dla aplikacji funkcjonalnych działających na systemie Linux w Planie Konsumpcji. (#1915)

  • Azure Functions 4.x używa Azure.Identity i Azure.Security.KeyVault.Secrets dla dostawcy Key Vault i odradza użycie Microsoft.Azure.KeyVault. Aby uzyskać więcej informacji na temat konfigurowania ustawień aplikacji funkcji, zobacz opcję Key Vault w Zarządzanie magazynem kluczy. (#2048)

  • Uruchomienie aplikacji funkcjonalnych, które współdzielą konta magazynu, jest teraz niemożliwe, gdy ich identyfikatory hostów są takie same. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące identyfikatora hosta. (#2049)

  • Azure Functions 4.x obsługuje nowsze wersje .NET. Zobacz Supported languages in Azure Functions aby uzyskać pełną listę wersji.

  • InvalidHostServicesException jest teraz błędem krytycznym. (#2045)

  • EnableEnhancedScopes jest domyślnie włączona. (#1954)

  • Usuń HttpClient jako zarejestrowaną usługę. (#1911)

  • Użyj jednego ładowacza klas w Java 11. (#1997)

  • Zatrzymaj ładowanie bibliotek roboczych w Java 8. (#1991)

  • Node.js wersji 10 i 12 nie są obsługiwane w Azure Functions 4.x. (#1999)

  • Serializacja danych wyjściowych w aplikacjach Node.js została zaktualizowana w celu rozwiązania poprzednich niespójności. (#2007)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

  • Python 3.6 nie jest obsługiwana w wersji Azure Functions 4.x. (#1999)

  • Transfer pamięci udostępnionej jest domyślnie włączony. (#1973)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

Następne kroki

Dowiedz się więcej o wersjach usługi Functions

  • Last updated on