Udostępnij za pośrednictwem

Migrowanie aplikacji z usługi Azure Functions w wersji 1.x do wersji 4.x

  • Artykuł

Ważne

Język Java nie jest obsługiwany przez wersję 1.x środowiska uruchomieniowego usługi Azure Functions. Być może zamiast tego chcesz przeprowadzić migrację aplikacji Java z wersji 3.x do wersji 4.x. Jeśli migrujesz aplikację funkcji w wersji 1.x, wybierz język C# lub JavaScript powyżej.

Ważne

Język TypeScript nie jest obsługiwany przez wersję 1.x środowiska uruchomieniowego usługi Azure Functions. Być może zamiast tego chcesz przeprowadzić migrację aplikacji TypeScript z wersji 3.x do wersji 4.x. Jeśli migrujesz aplikację funkcji w wersji 1.x, wybierz język C# lub JavaScript powyżej.

Ważne

Program PowerShell nie jest obsługiwany przez wersję 1.x środowiska uruchomieniowego usługi Azure Functions. Być może zamiast tego chcesz przeprowadzić migrację aplikacji programu PowerShell z wersji 3.x do wersji 4.x. Jeśli migrujesz aplikację funkcji w wersji 1.x, wybierz język C# lub JavaScript powyżej.

Ważne

Język Python nie jest obsługiwany przez wersję 1.x środowiska uruchomieniowego usługi Azure Functions. Być może zamiast tego chcesz przeprowadzić migrację aplikacji języka Python z wersji 3.x do wersji 4.x. Jeśli migrujesz aplikację funkcji w wersji 1.x, wybierz język C# lub JavaScript powyżej.

Ważne

Pomoc techniczna zakończy się w wersji 1.x środowiska uruchomieniowego usługi Azure Functions 14 września 2026 r. Zdecydowanie zalecamy przeprowadzenie migracji aplikacji do wersji 4.x, postępując zgodnie z instrukcjami w tym artykule.

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.

Jeśli używasz wersji 1.x środowiska uruchomieniowego w usłudze Azure Stack Hub, zobacz Najpierw zagadnienia dotyczące usługi Azure Stack Hub .

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu programu PowerShell, aby wygenerować listę aplikacji funkcji w subskrypcji, która jest obecnie docelowa w wersji 1.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 '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Wybierz docelową wersję platformy .NET

W wersji 1.x środowiska uruchomieniowego usługi Functions aplikacja funkcji języka C# jest przeznaczona dla platformy .NET Framework.

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

Jeśli aplikacja nie zależy od biblioteki lub interfejsu API dostępnego tylko dla programu .NET Framework, zalecamy zaktualizowanie do platformy .NET 8 w modelu izolowanego procesu roboczego. Wiele aplikacji w wersji 1.x jest przeznaczonych tylko dla platformy .NET Framework, ponieważ jest to to, co było dostępne podczas ich tworzenia. Dodatkowe możliwości są dostępne dla nowszych wersji platformy .NET, a jeśli aplikacja nie jest zmuszona do pozostanenia w programie .NET Framework ze względu na zależność, należy kierować do nowszej wersji. .NET 8 to w pełni wydana wersja z najdłuższym oknem obsługi z platformy .NET.

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

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 9. Jeśli chcesz zastosować wersję docelową, możesz dostosować przykłady platformy .NET 8 dla izolowanego modelu procesu roboczego.

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 wersji 4.x środowiska uruchomieniowego usługi Functions należy wykonać następujące zadania:

  1. Przejrzyj listę zmian zachowania po wersji 1.x. Migracja z wersji 1.x do wersji 4.x może również mieć wpływ na powiązania.
  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 narzędzi Azure Functions Core Tools.
  4. Zaktualizuj aplikację funkcji na platformie Azure do nowej wersji. Jeśli musisz zminimalizować przestoje, rozważ użycie miejsca przejściowego do przetestowania i zweryfikowania migrowanej aplikacji na platformie Azure w nowej wersji środowiska uruchomieniowego. Następnie możesz wdrożyć aplikację przy użyciu zaktualizowanych ustawień wersji w miejscu produkcyjnym. Aby uzyskać więcej informacji, zobacz Aktualizowanie przy użyciu miejsc.
  5. Opublikuj zmigrowany projekt do zaktualizowanej aplikacji funkcji.

Gdy używasz programu Visual Studio do publikowania projektu w wersji 4.x w istniejącej aplikacji funkcji w niższej wersji, podczas wdrażania zostanie wyświetlony monit o zaktualizowanie aplikacji funkcji do wersji 4.x. Ta aktualizacja używa tego samego procesu zdefiniowanego w aktualizacji bez miejsc.

Migrowanie projektu lokalnego

W poniższych sekcjach opisano aktualizacje, które należy wprowadzić w plikach projektu języka C#, aby można było uruchamiać je w jednej z obsługiwanych wersji platformy .NET w usłudze Functions w wersji 4.x. Wyświetlane aktualizacje są typowe dla większości projektów. Kod projektu może wymagać aktualizacji, które nie zostały wymienione w tym artykule, zwłaszcza w przypadku używania niestandardowych pakietów NuGet.

Migracja aplikacji funkcji języka C# z wersji 1.x do wersji 4.x środowiska uruchomieniowego usługi Functions wymaga wprowadzenia zmian w kodzie projektu. Wiele z tych zmian jest wynikiem zmian w języku C# i interfejsach API platformy .NET.

Wybierz kartę zgodną z docelową wersją platformy .NET i żądanym modelem procesów (proces procesu w procesie przetwarzania lub izolowanym procesie roboczym).

Napiwek

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

Plik projektu

Poniższy przykład to .csproj plik projektu, który działa w wersji 1.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </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 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>

Zmiany pakietu i przestrzeni nazw

Na podstawie modelu, do którego przeprowadzasz migrację, może być konieczne zaktualizowanie lub zmiana pakietów odwołań aplikacji. Podczas wdrażania pakietów docelowych należy zaktualizować przestrzeń nazw przy użyciu instrukcji i niektórych typów, do których się odwołujesz. Wpływ tych zmian przestrzeni nazw na using instrukcje można zobaczyć 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 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.*.

Powiązania usługi Notification Hubs i Mobile Apps są obsługiwane tylko w wersji 1.x środowiska uruchomieniowego. Podczas uaktualniania do wersji 4.x środowiska uruchomieniowego należy usunąć te powiązania na rzecz bezpośredniej pracy z tymi usługami przy użyciu ich zestawów SDK.

plik Program.cs

W większości przypadków migracja wymaga dodania następującego pliku 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 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.

plik host.json

Ustawienia w pliku host.json mają zastosowanie na poziomie aplikacji funkcji zarówno lokalnie, jak i na platformie Azure. W wersji 1.x plik host.json jest pusty lub zawiera pewne ustawienia, które mają zastosowanie do wszystkich funkcji w aplikacji funkcji. Aby uzyskać więcej informacji, zobacz Host.json v1. Jeśli plik host.json ma wartości ustawień, przejrzyj format host.json w wersji 2 pod kątem wszelkich zmian.

Aby uruchomić program w wersji 4.x, należy dodać "version": "2.0" go do pliku host.json. Należy również rozważyć dodanie logging do konfiguracji, jak w następujących przykładach:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

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.

plik local.settings.json

Plik local.settings.json jest używany tylko w przypadku uruchamiania lokalnego. Aby uzyskać informacje, zobacz Plik ustawień lokalnych. W wersji 1.x plik local.settings.json ma tylko dwie wymagane wartości:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

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 procesu w procesie wyizolowanego procesu roboczego należy zmienić FUNCTIONS_WORKER_RUNTIME wartość na "dotnet-isolated".

Zmiany nazwy klasy

Niektóre klasy kluczy zmieniły nazwy między wersją 1.x a wersją 4.x. Te zmiany są wynikiem zmian w interfejsach API platformy .NET lub różnic między procesem procesowym i izolowanym procesem roboczym. W poniższej tabeli przedstawiono kluczowe klasy platformy .NET używane przez funkcje, które mogą ulec zmianie podczas migracji:

Wersja 1.x .NET 8
FunctionName (atrybut) Function (atrybut)
TraceWriter ILogger<T>, ILogger
HttpRequestMessage HttpRequestData, HttpRequest (przy użyciu integracji z platformą ASP.NET Core)
HttpResponseMessage HttpResponseData, IActionResult (przy użyciu integracji z platformą ASP.NET Core)

Mogą również występować różnice nazw klas w powią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 zachowania po wersji 1.x , aby uzyskać dodatkowe zmiany, które mogą być konieczne w projekcie.

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.

Szablon wyzwalacza HTTP

Większość zmian kodu między wersją 1.x i wersją 4.x jest widoczna w funkcjach wyzwalanych przez protokół HTTP. Szablon wyzwalacza HTTP dla wersji 1.x wygląda następująco:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

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

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

W wersji 4.x szablon wyzwalacza HTTP 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 usługi Azure Functions 4.x:

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

  2. Przejdź do jednej z wersji Node.js obsługiwanych w wersji 4.x.

  3. Dodaj elementy i version extensionBundle do host.json, aby wyglądały jak w poniższym przykładzie:

    {
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

    Element extensionBundle jest wymagany, ponieważ po wersji 1.x powiązania są utrzymywane jako pakiety zewnętrzne. Aby uzyskać więcej informacji, zobacz Pakiety rozszerzeń.

  4. Zaktualizuj plik local.settings.json, aby miał co najmniej następujące elementy:

    {
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}

    Ustawienie AzureWebJobsStorage może być emulatorem magazynu Azurite lub rzeczywistym kontem usługi Azure Storage. Aby uzyskać więcej informacji, zobacz Emulator magazynu lokalnego.

Aktualizowanie aplikacji funkcji na platformie Azure

Przed opublikowaniem zmigrowanego projektu należy zaktualizować środowisko uruchomieniowe hosta aplikacji funkcji na platformie 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 bez miejsc , a następnie ponowne opublikowanie projektu aplikacji. Możesz również zminimalizować przestój w aplikacji i uprościć wycofywanie, aktualizując przy użyciu miejsc.

Aktualizowanie bez miejsc

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

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 systemami Windows i Linux.

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

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

Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

W tym przykładzie zastąp <APP_NAME> ciąg 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 miejsc

Użycie miejsc wdrożenia to dobry sposób aktualizowania aplikacji funkcji do środowiska uruchomieniowego w wersji 4.x z poprzedniej wersji. Za pomocą miejsca przejściowego możesz uruchomić aplikację w nowej wersji środowiska uruchomieniowego w miejscu przejściowym i przełączyć się do środowiska produkcyjnego po weryfikacji. Miejsca zapewniają również sposób zminimalizowania przestojów podczas aktualizacji. Jeśli musisz zminimalizować przestój, wykonaj kroki opisane w temacie Minimalna aktualizacja przestoju.

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

Aktualizacja Standardowa

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ę z miejsca przejściowego.

Polecenie Update-AzFunctionAppSetting cmdlet programu PowerShell nie obsługuje obecnie miejsc. Musisz użyć interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu 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> ciąg 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 platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

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

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> ciąg 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 zamianą upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  7. Użyj następującego polecenia, aby zamienić zaktualizowane miejsce przejściowe na środowisko produkcyjne:

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

Minimalna aktualizacja przestojów

Aby zminimalizować przestój w aplikacji produkcyjnej, możesz zamienić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie z miejsca przejściowego na środowisko produkcyjne. Następnie można zamienić zaktualizowaną wersję z wstępnie zainstalowanego miejsca przejściowego.

  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ć miejsce na nowe ustawienie w środowisku produkcyjnym, a jednocześnie przywrócić ustawienie wersji w miejscu 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 miejsca przejściowego mogą wystąpić w czasie między zamianą a wersją środowiska uruchomieniowego przywracaną w środowisku przejściowym. Ten błąd może wystąpić, ponieważ podczas WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 zamiany FUNCTIONS_EXTENSION_VERSION ustawienie jest usuwane tylko w środowisku przejściowym. Bez ustawienia wersji miejsce jest w złym stanie. Zaktualizowanie wersji w miejscu przejściowym bezpośrednio po zamianie powinno przywrócić miejsce do dobrego stanu i w razie potrzeby przywrócić zmiany. Jednak każde wycofanie zamiany wymaga również bezpośredniego usunięcia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 z środowiska produkcyjnego przed zamianą, aby zapobiec tym samym błędom w środowisku produkcyjnym widocznym 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 miejsca mają WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 ustawione.

  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 platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

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

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> ciąg 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 zamianą upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  8. Użyj następującego polecenia, aby zamienić zaktualizowane i wstępne miejsce przejściowe na środowisko produkcyjne:

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

Zachowanie zmienia się po wersji 1.x

Ta sekcja zawiera szczegółowe informacje o zmianach wprowadzonych po wersji 1.x w zachowaniach wyzwalacza i powiązań, a także w podstawowych funkcjach i zachowaniach funkcji.

Zmiany w wyzwalaczach i powiązaniach

Począwszy od wersji 2.x, należy zainstalować rozszerzenia dla określonych wyzwalaczy i powiązań używanych przez funkcje w aplikacji. Jedynym wyjątkiem dla tych wyzwalaczy HTTP i czasomierza, które nie wymagają rozszerzenia. Aby uzyskać więcej informacji, zobacz Rejestrowanie i instalowanie rozszerzeń powiązań.

Istnieje również kilka zmian w function.json lub atrybutów funkcji między wersjami. Na przykład właściwość usługi Event Hubs path ma teraz wartość eventHubName. Zobacz istniejącą tabelę powiązań, aby uzyskać linki do dokumentacji dla każdego powiązania.

Zmiany w funkcjach i funkcjach

Kilka funkcji zostało usuniętych, zaktualizowanych lub zastąpionych po wersji 1.x. Ta sekcja zawiera szczegółowe informacje o zmianach widocznych w nowszych wersjach po użyciu wersji 1.x.

W wersji 2.x wprowadzono następujące zmiany:

  • Klucze do wywoływania punktów końcowych HTTP są zawsze przechowywane zaszyfrowane w usłudze Azure Blob Storage. W wersji 1.x klucze były domyślnie przechowywane w usłudze Azure Files. Podczas migracji aplikacji z wersji 1.x do wersji 2.x istniejące wpisy tajne, które znajdują się w usłudze Azure Files, są resetowane.

  • Środowisko uruchomieniowe w wersji 2.x nie obejmuje wbudowanej obsługi dostawców elementów webhook. Ta zmiana została wprowadzona w celu zwiększenia wydajności. Nadal można używać wyzwalaczy HTTP jako punktów końcowych dla elementów webhook.

  • Aby ulepszyć monitorowanie, pulpit nawigacyjny usługi WebJobs w portalu, który używał AzureWebJobsDashboard ustawienia, został zastąpiony aplikacja systemu Azure Insights, który używa APPINSIGHTS_INSTRUMENTATIONKEY tego ustawienia. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure Functions.

  • Wszystkie funkcje w aplikacji funkcji muszą mieć ten sam język. Podczas tworzenia aplikacji funkcji należy wybrać stos środowiska uruchomieniowego dla aplikacji. Stos środowiska uruchomieniowego jest określany przez FUNCTIONS_WORKER_RUNTIME wartość w ustawieniach aplikacji. To wymaganie zostało dodane w celu zwiększenia zużycia i czasu uruchamiania. Podczas tworzenia aplikacji lokalnie należy również uwzględnić to ustawienie w pliku local.settings.json.

  • Domyślny limit czasu dla funkcji w planie usługi App Service został zmieniony na 30 minut. Możesz ręcznie zmienić limit czasu z powrotem na nieograniczony, używając ustawienia functionTimeout w host.json.

  • Ograniczenia współbieżności HTTP są domyślnie implementowane w przypadku funkcji planu zużycie z domyślnym 100 współbieżnymi żądaniami na wystąpienie. To zachowanie można zmienić w ustawieniu maxConcurrentRequests w pliku host.json.

  • Ze względu na ograniczenia platformy .NET Core usunięto obsługę funkcji skryptów języka F# (.fsx plików). Skompilowane funkcje języka F# (.fs) są nadal obsługiwane.

  • Format adresu URL elementów webhook wyzwalacza usługi Event Grid został zmieniony na następujący wzorzec: https://{app}/runtime/webhooks/{triggerName}.

  • Nazwy niektórych wstępnie zdefiniowanych metryk niestandardowych zostały zmienione po wersji 1.x. Duration element został zastąpiony elementem MaxDurationMs, MinDurationMsi AvgDurationMs. Success Rate zmieniono również nazwę na Success Rate.

Zagadnienia dotyczące usługi Azure Stack Hub

Usługa App Service w usłudze Azure Stack Hub nie obsługuje wersji 4.x usługi Azure Functions. Podczas planowania migracji poza wersję 1.x w usłudze Azure Stack Hub możesz wybrać jedną z następujących opcji:

  • Przeprowadź migrację do wersji 4.x hostowanej w chmurze publicznej usługi Azure Functions, korzystając z instrukcji opisanych w tym artykule. Zamiast uaktualniać istniejącą aplikację, należy utworzyć nową aplikację przy użyciu wersji 4.x, a następnie wdrożyć zmodyfikowany projekt.
  • Przełącz się do zadań WebJob hostowanych w planie usługi App Service w usłudze Azure Stack Hub.

Następne kroki

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