Udostępnij za pomocą

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

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 funkcyjnych do migracji

Użyj następującego skryptu programu PowerShell, aby wygenerować listę aplikacji funkcyjnych w subskrypcji, które obecnie działają 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 Model przetwarzania funkcji1,2
.NET 10 LTS (koniec wsparcia technicznego 14 listopada 2028 r.) Model izolowanego pracownika
.NET 9 STS (koniec wsparcia 10 listopada 2026 r.)3 Model izolowanego pracownika
.NET 8 LTS (koniec wsparcia 10 listopada 2026 r.) Model pracownika odizolowanego
Model w trakcie realizacji2
.NET Framework 4.8 Zobacz zasady Model izolowanego pracownika

1 Model izolowanego pracownika obsługuje wersje z długoterminowym wsparciem (LTS) i standardowym wsparciem (STS) platformy .NET oraz .NET Framework. Model wewnątrzprocesowy obsługuje tylko wersje LTS platformy .NET, kończąc się na wersji .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 Wsparcie dla modelu w toku kończy się 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 miało wcześniej oczekiwaną datę zakończenia wsparcia z 12 maja 2026 r. W oknie usługi platformy .NET 9 zespół platformy .NET rozszerzył wsparcie dla wersji STS do 24 miesięcy, począwszy od platformy .NET 9. Aby uzyskać więcej informacji, zobacz wpis w blogu.

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 w nowszych wersjach platformy .NET, a jeśli aplikacja nie jest zmuszona do pozostania w środowisku .NET Framework ze względu na zależność, powinieneś dążyć do nowszej wersji. .NET 8 to w pełni wydana wersja z najdłuższym oknem obsługi z platformy .NET.

Chociaż można zamiast tego użyć modelu przetwarzania w procesie, nie jest to zalecane, jeśli można tego uniknąć. Obsługa zostanie zakończona dla modelu przetwarzania 10 listopada 2026 r., dlatego należy przejść na model izolowanego pracownika przed tym terminem. 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 na model izolowanego pracownika, .NET Upgrade Assistant może również obsługiwać wiele niezbędnych zmian w kodzie.

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 10 (wersja zapoznawcza) ani .NET 9. Jeśli musisz kierować jedną z tych 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 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ę z zaktualizowanymi ustawieniami wersji do slotu produkcyjnego. Aby uzyskać więcej informacji, zobacz Aktualizowanie przy użyciu miejsc.
  5. Opublikuj zmigrowany projekt w zaktualizowanej aplikacji funkcjonalnej.

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 Update without slots.

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 zakładkę zgodną z docelową wersją platformy .NET i preferowanym modelem przetwarzania (proces w tym samym procesie lub izolowany proces roboczy).

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 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 lista, zastąp odwołanie do pakietu Microsoft.NET.Sdk.Functions 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 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. Po przyjęciu pakietów docelowych należy zaktualizować przestrzeń nazw w instrukcjach using oraz niektórych typach, 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 referencji do pakietów
Wyzwalacz czasomierza Dodaj
Microsoft.Azure.Functions.Worker.Extensions.Timer
Więzy 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 blobów 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 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
Durable Functions Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(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 istotne zmiany 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 pracownika nie powinna odwoływać się do żadnych pakietów w przestrzeniach nazw Microsoft.Azure.WebJobs.* ani Microsoft.Azure.Functions.Extensions. Jeśli masz jakiekolwiek pozostałe odwołania do tych, należy je usunąć.

Napiwek

Aplikacja może również zależeć od typów bibliotek Azure SDK, jako część wyzwalaczy i powiązań lub jako zależność autonomiczna. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń Functions są zgodne z najnowszymi wersjami zestawu Azure SDK dla platformy .NET, prawie wszystkie pakiety mają formę 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 wywołaniem 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ę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 jako część HostBuilder, mają podobne zastosowanie tylko do kodu w projekcie. Platforma potrzebuje również konfiguracji wyzwalaczy i powiązań, które powinny być udostępniane poprzez ustawienia aplikacji, odwołania do usługi Key Vault lub funkcje odwołań do usługi App Configuration.

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 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 jakichkolwiek 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 w ramach procesu do uruchamiania w wyizolowanym procesie roboczym należy zmienić wartość FUNCTIONS_WORKER_RUNTIME 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 w toku a 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. Upewnij się, że sprawdzisz zmiany zachowania po wersji 1.x, aby dowiedzieć się, czy potrzebne są dodatkowe zmiany 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ę na 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

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 zarówno elementy version i 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 lokalnego magazynu.

Zaktualizuj aplikację funkcji w 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 slotów, 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 w ustawieniach aplikacji ~4 w aplikacji funkcji na platformie Azure. Musisz wykonać inną procedurę na stronie ze slotami.

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 systemie Windows należy również włączyć platformę .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>

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> nazwą aplikacji funkcji oraz <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. Sloty również umożliwiają ograniczenie przestojów podczas aktualizacji. Jeśli musisz zminimalizować czas przestoju, wykonaj kroki opisane w aktualizacji minimalizującej przestój.

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

Standardowa Aktualizacja

Jeśli aplikacja funkcji z obsługą slotów może obsłużyć przestój spowodowany pełnym ponownym uruchomieniem, możesz zaktualizować ustawienie WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS bezpośrednio w slocie 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 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 oraz <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ć slot przejściowy 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 systemie Windows należy również włączyć platformę .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>

    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> nazwą aplikacji funkcji oraz <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 funkcjonalna działa poprawnie w zaktualizowanym środowisku przejściowym.

  7. Użyj następującego polecenia, aby przenieść zaktualizowany slot tymczasowy do środowiska produkcyjnego.

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

Aktualizacja z minimalnym czasem przestoju

Aby zminimalizować przestój w aplikacji produkcyjnej, możesz przenieść ustawienia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ze środowiska przejściowego do produkcyjnego. 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 lokacji przejściowej mogą wystąpić w okresie między zamianą a przywracaniem wersji uruchomieniowej w lokacji przejściowej. 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, twój gniazdo 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 procesu zamiany wymaga bezpośredniego usunięcia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 ze środowiska produkcyjnego przed przywróceniem, aby zapobiec błędom, które wystąpiły w fazie testowej. 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ć slot przejściowy 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 systemie Windows należy również włączyć platformę .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>

    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> nazwą aplikacji funkcji oraz <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 funkcjonalna działa poprawnie w zaktualizowanym środowisku przejściowym.

  8. Użyj następującego polecenia, aby zamienić zaktualizowany i przygotowany slot tymczasowy 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. Jedyny wyjątek stanowią wyzwalacze HTTP i czasomierza, które nie wymagają rozszerzenia. Aby uzyskać więcej informacji, odwiedź 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 funkcjonalności

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 wbudowanego wsparcia dla dostawców webhooków. 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 z funkcjami muszą mieć jednolity język. Podczas tworzenia aplikacji funkcji należy wybrać środowisko uruchomieniowe dla aplikacji. Stos wykonawczy jest określany przez wartość FUNCTIONS_WORKER_RUNTIME w ustawieniach aplikacji. To wymaganie zostało dodane w celu poprawy użycia zasobów 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 Konsumpcja, ze standardową liczbą 100 współbieżnych żądań na instancję. 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 dla webhooków wyzwalaczy Event Grid został zmieniony na następujący schemat: 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 WebJobs hostowanych w planie usługi App Service w Azure Stack Hub.

Następne kroki

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

  • Last updated on