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

Ważne

Java nie jest obsługiwana przez wersję 1.x środowiska uruchomieniowego Azure Functions. Być może zamiast tego chcesz zmigrować swoją aplikację 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 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 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

Python nie jest obsługiwana przez wersję 1.x środowiska uruchomieniowego Azure Functions. Być może zamiast tego chcesz migrować aplikację 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

Support zakończy się w wersji 1.x środowiska uruchomieniowego 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 Azure Stack Hub, najpierw zobacz Considerations for Azure Stack Hub.

Identyfikowanie aplikacji funkcyjnych do migracji

Uruchom następujący skrypt PowerShell w Azure Cloud Shell, aby wygenerować listę aplikacji funkcji w subskrypcji, które obecnie celują w wersję 1.x.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     $AppSettings = Get-AzFunctionAppSetting -Name $App.Name -ResourceGroupName $App.ResourceGroupName
     if ($AppSettings.FUNCTIONS_EXTENSION_VERSION -like '*1*')
     {
          $AppInfo.Add($App.Name, $AppSettings.FUNCTIONS_EXTENSION_VERSION)
     }
}

$AppInfo

Jeśli uruchamiasz poza Cloud Shell, musisz najpierw ustawić aktywną subskrypcję.

$Subscription = '<SUBSCRIPTION_ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

W tym przykładzie zastąp ciąg "<SUBSCRIPTION_ID>" identyfikatorem subskrypcji.

Wybierz docelową wersję .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ę .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 pomocy technicznej typ wydania 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 .NET długoterminowe wsparcie (LTS) i standardowe wsparcie (STS), a także .NET Framework. Model przetwarzania in-process obsługuje tylko wersje LTS .NET, kończące się .NET 8. Aby uzyskać pełne porównanie funkcji i możliwości pomiędzy dwoma modelami, zobacz Różnice pomiędzy procesem wewnętrznym a izolowanym procesem roboczym w .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 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

Jeśli aplikacja nie zależy od biblioteki lub interfejsu API dostępnego tylko dla platformy .NET Framework, zalecamy zaktualizowanie do .NET 8 w modelu izolowanego procesu roboczego. Wiele aplikacji w wersji 1.x jest skierowanych na .NET Framework tylko dlatego, że to właśnie było dostępne w momencie ich tworzenia. Dodatkowe możliwości są dostępne dla nowszych wersji .NET, a jeśli aplikacja nie jest zmuszona do pozostanenia na platformie .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 pomocy technicznej z .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 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 roboczy, .NET Upgrade Assistant jest w stanie obsłużyć wiele niezbędnych zmian w kodzie.

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

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. 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 Azure Functions Core Tools.
  4. 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ę 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.

Jeśli używasz Visual Studio do publikowania projektu w wersji 4.x w istniejącej aplikacji funkcji, która jest w niższej wersji niż 4.x, 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

W poniższych sekcjach opisano aktualizacje, które należy wprowadzić w plikach projektu C#, aby można było uruchamiać je w jednej z obsługiwanych wersji .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 .NET.

Wybierz kartę zgodną z docelową wersją .NET i wybranym modelem procesu (proces w procesie lub izolowanym procesem roboczym).

Napiwek

Jeśli przechodzisz do wersji LTS lub STS .NET przy użyciu izolowanego modelu procesu roboczego, .NET Upgrade Assistant może automatycznie wprowadzić wiele 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 list, 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 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 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 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 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 Service Bus ma zmiany powodujące niekompatybilność w strukturze między wersjami 4.x a 5.x. Aby uzyskać więcej informacji, zobacz Azure Service Bus powiązania dla Azure Functions.

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, należy je usunąć.

Napiwek

Aplikacja może również zależeć od typów Azure SDK, zarówno w ramach wyzwalaczy i powiązań, jak i jako samodzielna zależność. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń usługi Functions współpracują z najnowszymi wersjami Azure SDK dla .NET, a niemal wszystkie pakiety dostępne są w formacie 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 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 zachować FrameworkReference w 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 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 host.json

Ustawienia w pliku host.json mają zastosowanie na poziomie aplikacji funkcji zarówno lokalnie, jak i w 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 .NET lub w różnicach między procesem procesowym a izolowanym procesem roboczym. W poniższej tabeli przedstawiono kluczowe klasy .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 ASP.NET Core)
HttpResponseMessage HttpResponseData, IActionResult (przy użyciu integracji 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ę 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

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 Azure Functions 4.x:

  1. Zaktualizuj lokalną instalację 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 magazynu Azure. Aby uzyskać więcej informacji, zobacz Emulator lokalnego magazynu.

Uaktualnij swoją aplikację funkcjonalną 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 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 aplikacji na wartość ~4 w aplikacji funkcji w 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 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 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ć 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 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 .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 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 .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 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 Azure Files. Podczas migracji aplikacji z wersji 1.x do wersji 2.x istniejące wpisy tajne, które znajdują się w 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 WebJobs w portalu, który używał ustawienia AzureWebJobsDashboard, jest zastępowany przez aplikacja systemu Azure Insights, który używa ustawienia APPINSIGHTS_INSTRUMENTATIONKEY. Aby uzyskać więcej informacji, zobacz Monitor 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 .NET Core obsługa skryptu języka F# (.fsx plików) została usunięta. 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 Azure Stack Hub

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

  • Przeprowadź migrację do wersji 4.x hostowanej w chmurze publicznej Azure Functions, korzystając z instrukcji 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.
  • Przejdź do WebJobs hostowanej 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