Migrace aplikací z Azure Functions verze 3.x na verzi 4.x

Důležité

Od 13. prosince 2022 aplikace funkcí běžící na verzích 2.x a 3.x modulu runtime Azure Functions dosáhly konce rozšířené podpory. Další informace naleznete v tématu Vyřazené verze.

Azure Functions verze 4.x je vysoce zpětně kompatibilní s verzí 3.x. Většina aplikací by se měla bezpečně migrovat na verzi 4.x, aniž by vyžadovala významné změny kódu. Další informace o verzích funkcí modulu runtime najdete v tématu Azure Functions přehled verzí modulu runtime.

Důležité

Aplikace funkcí stále spouštějí modul runtime verze v3 s ukončenou podporou na Linuxu v plánu spotřeby přestanou běžet po 30. září 2026. Pokud se chcete vyhnout přerušení služeb, migrujte aplikaci do modulu runtime v4.

Možnost hostovat funkční aplikace na Linuxu v plánu Consumption bude vyřazena z provozu 30. září 2028. Plán spotřeby pro Linux již nedostává žádné nové funkce ani jazykové verze. Aplikace spuštěné na Windows v plánu Consumption nejsou aktuálně ovlivněné. Migrujte své aplikace do plánu Flex Consumption před datem vyřazení.

Tento článek vás provede procesem bezpečné migrace aplikace funkcí, aby běžela ve verzi 4.x modulu runtime Služby Functions. Vzhledem k tomu, že pokyny pro migraci projektů jsou závislé na jazyce, nezapomeňte zvolit vývojový jazyk ze selektoru v horní části článku.

Identifikace aplikací funkcí, které se mají migrovat

Pomocí následujícího skriptu PowerShellu vygenerujte seznam aplikací funkcí ve vašem předplatném, které aktuálně cílí na verze 2.x nebo 3.x:

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

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Volba cílové verze .NET

Ve verzi 3.x modulu runtime Functions aplikace funkcí C# cílí na .NET Core 3.1 s procesovým modelem nebo na .NET 5 s izolovaným pracovním modelem.

Při migraci aplikace funkcí máte možnost zvolit cílovou verzi .NET. Projekt jazyka C# můžete aktualizovat na jednu z následujících verzí .NET podporovaných funkcí verze 4.x:

verze .NET .NET Oficiální zásady podpory typ verze Modelprocesu funkcí 1,2
.NET 10 LTS (konec podpory 14. listopadu 2028) Izolovaný model pracovního procesu
.NET 9 STS (konec podpory 10. listopadu 2026)3 Izolovaný model pracovního procesu
.NET 8 LTS (konec podpory 10. listopadu 2026) Model izolovaného pracovního procesu
Model v procesu2
.NET Framework 4.8 Zobrazit zásady Izolovaný model pracovního procesu

1 Izolovaný pracovní model isolated worker podporuje verze dlouhodobé podpory (LTS) a standardní podpory (STS) pro .NET a .NET Framework. Model in-process podporuje pouze verze LTS .NET končící na .NET 8. Úplné porovnání funkcí a vlastností mezi těmito dvěma modely najdete v informacích Differences between in-process and isolate worker process .NET Azure Functions.

2 Podpora modelu v procesu končí 10. listopadu 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste své aplikace migrovat do izolovaného pracovního modelu.

3 .NET 9 dříve mělo očekávané datum ukončení podpory 12. května 2026. Během .NET 9 servisního okna rozšířil tým .NET podporu verzí služby STS na 24 měsíců počínaje .NET 9. Další informace najdete v blogovém příspěvku.

Návod

Doporučujeme aktualizovat na .NET 8 v izolovaném modelu pracovního procesu. .NET 8 je plně vydaná verze s nejdelším oknem podpory z .NET.

I když se místo toho můžete rozhodnout použít model v procesu, nedoporučujeme tento přístup, pokud se tomu můžete vyhnout. Podpora modelu v procesu skončí 10. listopadu 2026, takže před tím budete muset přejít na izolovaný model pracovního procesu. Při migraci na verzi 4.x se sníží celková požadovaná úsilí a izolovaný model pracovního procesu poskytne aplikaci přidatné výhody, včetně možnosti snadněji cílit na budoucí verze .NET. Pokud přecházíte na model izolovaného pracovníka, nástroj .NET Upgrade Assistant může zpracovat také řadu potřebných změn kódu.

Tato příručka neobsahuje konkrétní příklady pro .NET 10 (Preview) nebo .NET 9. Pokud potřebujete cílit na jednu z těchto verzí, můžete přizpůsobit .NET 8 příklad.

Příprava migrace

Pokud jste to ještě neudělali, pomocí 0>Azure PowerShell

Před migrací aplikace do modulu runtime Functions verze 4.x byste měli provést následující úlohy:

  1. Projděte si seznam zásadních změn mezi 3.x a 4.x.
  2. Proveďte kroky v části Migrace místního projektu a proveďte migraci místního projektu na verzi 4.x.
  3. Po migraci projektu plně otestujte aplikaci místně pomocí verze 4.x nástroje Azure Functions Core Tools.
  4. Spusťte validátor před upgradem v aplikaci hostované v Azure a vyřešte případné zjištěné problémy.
  5. Aktualizujte aplikaci funkcí v Azure na novou verzi. Pokud potřebujete minimalizovat výpadky, zvažte použití staging slotu k otestování a ověření migrované aplikace v Azure v nové verzi modulu runtime. Poté můžete nasadit aktualizovanou verzi aplikace do produkčního slotu. Další informace najdete v tématu Aktualizace pomocí slotů.
  6. Publikujte migrovaný projekt do aktualizované aplikace funkcí.

Když použijete Visual Studio k publikování projektu verze 4.x do existující aplikace funkcí v nižší verzi, zobrazí se výzva k Visual Studio aktualizaci aplikace funkcí na verzi 4.x během nasazování. Tato aktualizace používá stejný proces definovaný v aktualizaci bez slotů.

Migrace místního projektu

Pokyny k upgradu jsou závislé na jazyce. Pokud váš jazyk nevidíte, vyberte ho ze selektoru v horní části článku.

Zvolte kartu, která odpovídá cílové verzi .NET a požadovanému modelu procesu (v procesu nebo izolovanému pracovnímu procesu).

Návod

Pokud přecházíte na verzi LTS nebo STS .NET pomocí izolovaného pracovního modelu, můžete použít pomocníka pro upgrade .NET upgrade k automatickému provedení mnoha změn uvedených v následujících částech.

Soubor projektu

Následující příklad je soubor projektu .csproj, který používá .NET Core 3.1 ve verzi 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Pomocí jednoho z následujících postupů aktualizujte tento soubor XML tak, aby běžel ve službě Functions verze 4.x:

Tyto kroky předpokládají místní projekt jazyka C#; Pokud vaše aplikace místo toho používá skript jazyka C# (soubory .csx ), měli byste před pokračováním převést na projektový model .

V souboru projektu XML .csproj jsou vyžadovány následující změny:

  1. Nastavte hodnotu PropertyGroup. TargetFramework na net8.0.

  2. Nastavte hodnotu PropertyGroup. AzureFunctionsVersion na v4.

  3. Přidejte následující OutputType prvek do PropertyGroup:

    <OutputType>Exe</OutputType>

  4. V sadě ItemGroup. PackageReference seznam nahraďte odkaz na balíček Microsoft.NET.Sdk.Functions následujícími odkazy:

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

    Poznamenejte si všechny odkazy na jiné balíčky v oborech názvů Microsoft.Azure.WebJobs.*. Tyto balíčky nahradíte v pozdějším kroku.

  5. Přidejte následující nové ItemGroup:

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Po provedení těchto změn by aktualizovaný projekt měl vypadat jako v následujícím příkladu:

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

Změny balíčků a oborů názvů

Na základě modelu, na který migrujete, budete možná muset aktualizovat nebo změnit balíčky, na které odkazuje vaše aplikace. Když použijete cílové balíčky, musíte aktualizovat obor názvů pro příkazy using a některé typy, na které odkazujete. Účinek těchto změn using oboru názvů můžete zobrazit na příkazy v příkladech šablony HTTP triggeru dále v tomto článku.

Pokud jste to ještě neudělali, aktualizujte projekt tak, aby odkazoval na nejnovější stabilní verze.

V závislosti na aktivačních událostech a vazbách, které vaše aplikace používá, může být potřeba, aby odkazovala na jinou sadu balíčků. Následující tabulka uvádí nahrazení některých nejčastěji používaných rozšíření:

Scénář Změny odkazů na balíčky
Spouštěč časovače Přidat
Microsoft.Azure. Functions.Worker.Extensions.Timer
Vazby úložiště Nahradit
Microsoft.Azure.WebJobs.Extensions.Storage
s
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Microsoft.Azure.Functions.Worker.Extensions.Tables
Vazby objektů blob Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs
Svázání fronty Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Vazby tabulek Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Tables
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Tables
Vazby databáze Cosmos Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
a/nebo
Microsoft.Azure.WebJobs.Extensions.DocumentDB
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.CosmosDB
Vazby na Service Bus Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.ServiceBus
Vazby pro Event Hubs Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.EventHubs
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.EventHubs
Vazby Event Gridu Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.EventGrid
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.EventGrid
Vazby služby SignalR Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.SignalRService
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.SignalRService
Durable Functions Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.DurableTask
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(Zprostředkovatel úložiště SQL)		 Nahraďte odkazy na
Microsoft.DurableTask.SqlServer.AzureFunctions
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Zprostředkovatel úložiště Netherite)		 Nahraďte odkazy na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.DurableTask.Netherite
Propojení služby SendGrid Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.SendGrid
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.SendGrid
Kafka propojení Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Kafka
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.Kafka
Vazby RabbitMQ Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.RabbitMQ
Injektáž závislostí
a konfigurace spuštění		 Odstraňte odkazy na
Microsoft.Azure.Functions.Extensions
(Izolovaný model pracovního procesu tuto funkci poskytuje ve výchozím nastavení.)

Podívejte se na Podporovaná propojení pro úplný seznam rozšíření, která je potřeba zvážit, a konzultujte dokumentaci každého rozšíření pro úplné pokyny k instalaci izolovaného modelu procesu. Nezapomeňte nainstalovat nejnovější stabilní verzi všech balíčků, na které cílíte.

Návod

Jakékoli změny verzí rozšíření během tohoto procesu mohou také vyžadovat aktualizaci vašeho souboru host.json. Nezapomeňte si přečíst dokumentaci jednotlivých rozšíření, která používáte. Například rozšíření Service Bus má zásadní změny struktury mezi verzemi 4.x a 5.x. Pro více informací se podívejte na propojení Azure Service Bus pro Azure Functions.

Aplikace izolovaného pracovního modelu by neměla odkazovat na žádné balíčky v oborech názvů Microsoft.Azure.WebJobs.* ani Microsoft.Azure.Functions.Extensions. Pokud máte na tyto nějaké odkazy, měly by se odebrat.

Návod

Vaše aplikace může také záviset na typech Azure SDK, a to buď jako součást triggerů a vazeb, nebo jako samostatná závislost. Tuto příležitost byste měli využít také k jejich aktualizaci. Nejnovější verze rozšíření Functions fungují s nejnovějšími verzemi Azure SDK pro .NET, přičemž téměř všechny balíčky mají podobu Azure.*.

Program.cs soubor

Při migraci na spuštění v izolovaném pracovním procesu musíte do projektu přidat následující soubor Program.cs:

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();

Tento příklad zahrnuje integraci ASP.NET Core ke zlepšení výkonu a poskytnutí známého programovacího modelu, když vaše aplikace používá triggery HTTP. Pokud nemáte v úmyslu používat triggery HTTP, můžete volání ConfigureFunctionsWebApplication nahradit voláním ConfigureFunctionsWorkerDefaults. Pokud to uděláte, můžete z souboru projektu odebrat odkaz na Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore. Pokud ale chcete dosáhnout nejlepšího výkonu, i u funkcí s jinými typy triggerů, měli byste ponechat FrameworkReference v ASP.NET Core.

Soubor Program.cs nahradí libovolný soubor, který má FunctionsStartup atribut, což je obvykle Startup.cs soubor. Na místech, kde by váš FunctionsStartup kód odkazoval na IFunctionsHostBuilder.Services, můžete přidat příkazy přímo do metody .ConfigureServices() v HostBuilder ve vašem Program.cs. Další informace o práci s Program.cs najdete v tématu Spuštění a konfigurace v průvodci izolovaným pracovním modelem.

Mezi výchozí Program.cs příklady, které jsme dříve popsali, patří nastavení Application Insights. V Program.cs musíte také nakonfigurovat veškeré filtrování protokolu, které by se mělo vztahovat na protokoly pocházející z kódu v projektu. V izolovaném modelu pracovního procesu host.json soubor řídí pouze události generované modulem runtime hostitele Služby Functions. Pokud v Program.cs nenakonfigurujete pravidla filtrování, můžou se v telemetrických datech zobrazovat rozdíly v úrovních protokolu pro různé kategorie.

I když můžete registrovat vlastní zdroje konfigurace jako součást projektu HostBuilder, platí to podobně pouze pro kód v projektu. Platforma také potřebuje konfiguraci spouštění a vazby, která by měla být poskytována prostřednictvím nastavení aplikace, odkazy na Key Vault nebo odkazy na konfiguraci aplikace.

Po přesunutí všech existujících FunctionsStartup souborů do souboru Program.cs můžete atribut odstranit FunctionsStartup a třídu, na kterou byl použit.

soubor local.settings.json

Soubor local.settings.json se používá pouze při místním spuštění. Informace najdete v Místním souboru nastavení.

Při migraci na verzi 4.x se ujistěte, že soubor local.settings.json obsahuje alespoň následující prvky:

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

Poznámka:

Při migraci z probíhajícího procesu na spuštění v izolovaném pracovním procesu je potřeba změnit FUNCTIONS_WORKER_RUNTIME hodnotu na dotnet-isolated.

soubor host.json

Soubor host.json nevyžaduje žádné změny. Pokud je však konfigurace vašeho Application Insights v tomto souboru propojena s projektem modelu, který probíhá, možná budete chtít provést další změny ve svém Program.cs souboru. Soubor host.json řídí pouze protokolování z modulu runtime hostitele Functions a v izolovaném pracovním modelu pocházejí některé z těchto protokolů přímo z vaší aplikace a poskytují větší kontrolu. Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .

Změny názvu třídy

Některé klíčové třídy změnily názvy mezi verzemi. Tyto změny jsou výsledkem změn v rozhraních API .NET nebo rozdílech mezi procesem v procesu a izolovaným pracovním procesem. Následující tabulka označuje klíčové .NET třídy používané funkcemi, které by se mohly při migraci změnit:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (atribut) Function (atribut) Function (atribut)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (s použitím integrace ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (s použitím integrace ASP.NET Core)
FunctionsStartup (atribut) Místo toho se používá Program.cs Místo toho se používá Program.cs

Ve vazbách mohou být také rozdíly v názvech tříd. Další informace naleznete v článcích zaměřených na konkrétní vazby.

Jiné změny kódu

V této části jsou zvýrazněné další změny kódu, které je potřeba vzít v úvahu při práci s migrací. Tyto změny nejsou potřeba pro všechny aplikace, ale měli byste vyhodnotit, jestli jsou pro vaše scénáře relevantní. Nezapomeňte zkontrolovat zásadní změny mezi verzemi 3.x a 4.x a dalšími změnami, které možná budete muset udělat v projektu.

Serializace JSON

Ve výchozím nastavení používá izolovaný pracovní model system.Text.Json pro serializaci JSON. Pokud chcete upravit možnosti serializátoru nebo přepnout na JSON.NET (Newtonsoft.Json), přečtěte si téma Usměrování serializace JSON.

Úrovně protokolů a filtrování Application Insights

Protokoly je možné odesílat do Application Insights jak z runtime hostitele funkcí, tak z kódu vašeho projektu. host.json umožňuje konfigurovat pravidla pro protokolování hostitele, ale pokud chcete mít kontrolu nad protokoly pocházejícími z vašeho kódu, je potřeba nakonfigurovat pravidla filtrování jako součást Program.cs. Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .

Šablona triggeru HTTP

Rozdíly mezi procesem v procesu a izolovaným pracovním procesem se dají zobrazit ve funkcích aktivovaných protokolem HTTP. Šablona triggeru HTTP pro verzi 3.x (v procesu) vypadá jako v následujícím příkladu:

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

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

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

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

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

            return new OkObjectResult(responseMessage);
        }
    }
}

Šablona triggeru HTTP pro migrovanou verzi vypadá jako v následujícím příkladu:

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

Aktualizace projektu na Azure Functions 4.x:

  1. Aktualizujte místní instalaci nástroje Azure Functions Core Tools na verzi 4.x.

  2. Aktualizujte sadu rozšíření Azure Functions vaší aplikace na 2.x nebo vyšší. Další informace najdete v tématu Zásadní změny.

  1. V případě potřeby přejděte na jednu z verzí Java podporovanou ve verzi 4.x.

  2. Aktualizujte soubor aplikace POM.xml tak, aby upravte FUNCTIONS_EXTENSION_VERSION nastavení na ~4, jak je znázorněno v následujícím příkladu:

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. V případě potřeby přejděte na jednu z Node.js verzí podporovaných ve verzi 4.x.
  1. Tuto příležitost využijte k upgradu na PowerShell 7.2, který se doporučuje. Další informace najdete ve verzích PowerShellu.
  1. Pokud používáte Python 3.6, přejděte na jednu z podporovaných verzí.

Spuštění validátoru před upgradem

Azure Functions poskytuje validátor před upgradem, který vám pomůže identifikovat potenciální problémy při migraci aplikace funkcí na verzi 4.x. Spuštění validátoru před upgradem:

  1. Na portálu Azure přejděte do aplikace funkcí.

  2. Otevřete stránku Diagnostika a řešení problémů.

  3. V Diagnostice aplikace funkcí začněte psát Functions 4.x Pre-Upgrade Validator a pak ho vyberte ze seznamu.

  4. Po dokončení ověření si projděte doporučení a vyřešte případné problémy v aplikaci. Pokud potřebujete v aplikaci provést změny, nezapomeňte ověřit změny ve verzi 4.x prostředí runtime Functions, a to buď místně pomocí nástrojů Azure Functions Core Tools verze 4, nebo použitím přípravného slotu.

Aktualizace aplikace funkcí v Azure

Než publikujete migrovaný projekt, musíte aktualizovat modul runtime hostitele aplikace funkcí v Azure na verzi 4.x. Verze modulu runtime používaná hostitelem Služby Functions je řízena FUNCTIONS_EXTENSION_VERSION nastavením aplikace, ale v některých případech se musí aktualizovat i jiná nastavení. Změny kódu i změny nastavení aplikace vyžadují restartování aplikace funkcí.

Nejjednodušší způsob je aktualizovat bez slotů a pak znovu publikovat projekt aplikace. Můžete také minimalizovat výpadky aplikace a zjednodušit vrácení zpět aktualizací pomocí slotů.

Aktualizace bez slotů

Nejjednodušší způsob, jak aktualizovat na v4.x, je nastavit nastavení aplikace FUNCTIONS_EXTENSION_VERSION na ~4 v aplikaci funkcí v Azure. Na webu s sloty musíte postupovat jinak .

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

Musíte také nastavit jiné nastavení, které se liší mezi Windows a Linuxem.

Při spuštění na Windows musíte také povolit .NET 8.0, což vyžaduje verze 4.x modulu runtime.

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

.NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím na Windows.

V tomto příkladu nahraďte <APP_NAME> názvem vaší aplikace funkcí a <RESOURCE_GROUP_NAME> názvem skupiny prostředků.

Teď můžete znovu publikovat projekt aplikace, který byl migrován, aby běžel ve verzi 4.x.

Aktualizujte pomocí slotů

Použití nasazovacích slotů je dobrý způsob, jak aktualizovat svou aplikaci funkcí na runtime v4.x z předchozí verze. Pomocí přípravného slotu můžete aplikaci spustit na nové verzi modulu runtime v přípravném slotu a po ověření přepnout do produkčního prostředí. Sloty také poskytují způsob, jak minimalizovat výpadky během aktualizace. Pokud potřebujete minimalizovat výpadky, postupujte podle kroků v aktualizaci minimálního výpadku.

Po ověření aplikace v aktualizovaném slotu můžete aplikaci a nastavení nové verze prohodit do produkčního prostředí. Tato výměna vyžaduje nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v produkční pozici. Způsob přidání tohoto nastavení má vliv na množství výpadků potřebných pro aktualizaci.

Standardní aktualizace

Pokud vaše aplikace funkcí s podporou slotu dokáže zvládnout výpadek v případě úplného restartování, můžete nastavení aktualizovat WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS přímo v produkčním slotu. Vzhledem k tomu, že změna tohoto nastavení přímo v produkčním slotu způsobí restartování, které ovlivňuje dostupnost, zvažte tuto změnu v době omezeného provozu. Pak můžete vyměnit aktualizovanou verzi z přípravného slotu.

Cmdlet Update-AzFunctionAppSetting PowerShellu momentálně nepodporuje sloty. Musíte použít Azure CLI nebo portál Azure.

  1. K nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v produkčním slotu použijte následující příkaz:

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

    V tomto příkladu nahraďte <APP_NAME> názvem vaší aplikace funkcí a <RESOURCE_GROUP_NAME> názvem skupiny prostředků. Tento příkaz způsobí restartování aplikace spuštěné v produkčním slotu.

  2. K nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS v přípravném slotu použijte následující příkaz:

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

  3. Pomocí následujícího příkazu změňte FUNCTIONS_EXTENSION_VERSION a aktualizujte přípravný slot na novou verzi modulu runtime:

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

  4. Verze 4.x modulu runtime Functions vyžaduje .NET 6 v Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime na .NET 6:

    Při spuštění na Windows musíte také povolit .NET 8.0, což vyžaduje verze 4.x modulu runtime.

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

    .NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím na Windows.

    V tomto příkladu nahraďte <APP_NAME> názvem vaší aplikace funkcí a <RESOURCE_GROUP_NAME> názvem skupiny prostředků.

  5. Pokud váš projekt kódu potřeboval jakékoli aktualizace k běhu na verzi 4.x, nyní nasaďte tyto aktualizace do testovacího prostředí.

  6. Před prohozením ověřte, že vaše aplikace s funkcemi funguje správně v aktualizovaném přípravném prostředí.

  7. K prohození aktualizovaného přípravného slotu do produkčního prostředí použijte následující příkaz:

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

Aktualizace s minimálním výpadkem

Pokud chcete minimalizovat výpadky v produkční aplikaci, můžete prohodit nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ze staging slotu do produkčního prostředí. Potom můžete prohodit aktualizovanou verzi z předem připraveného přípravného slotu.

  1. Pomocí následujícího příkazu nastavte WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v přípravném slotu:

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

  2. Pomocí následujících příkazů prohodíte slot s novým nastavením do produkčního prostředí a zároveň obnovíte nastavení verze v přípravném slotu.

    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>

    Chyby z přípravného slotu se můžou zobrazit během doby mezi prohozením slotu a obnovou verze běhového prostředí na přípravném slotu. K této chybě může dojít, pokud se WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nachází pouze v přípravné prostředí během prohození, což odstraní nastavení FUNCTIONS_EXTENSION_VERSION v přípravné prostředí. Bez nastavení verze je váš slot ve špatném stavu. Aktualizace verze v úložném slotu hned po prohození by měla slot vrátit do dobrého stavu a v případě potřeby můžete vrátit zpět změny. Jakékoli vrácení prohození ale také vyžaduje, abyste před přepnutím zpět odebrali WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 přímo z produkčního prostředí, abyste zabránili stejným chybám v produkčním prostředí, které se projeví v přípravném prostředí. Tato změna v produkčním nastavení by pak způsobila restartování.

  3. K opětovnému nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v přípravném slotu použijte následující příkaz:

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

    V tuto chvíli jsou oba sloty nastavené WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.

  4. Pomocí následujícího příkazu změňte FUNCTIONS_EXTENSION_VERSION a aktualizujte přípravný slot na novou verzi modulu runtime:

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

  5. Verze 4.x modulu runtime Functions vyžaduje .NET 6 v Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime na .NET 6:

    Při spuštění na Windows musíte také povolit .NET 8.0, což vyžaduje verze 4.x modulu runtime.

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

    .NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím na Windows.

    V tomto příkladu nahraďte <APP_NAME> názvem vaší aplikace funkcí a <RESOURCE_GROUP_NAME> názvem skupiny prostředků.

  6. Pokud váš projekt kódu potřeboval jakékoli aktualizace k běhu na verzi 4.x, nyní nasaďte tyto aktualizace do testovacího prostředí.

  7. Před prohozením ověřte, že vaše aplikace s funkcemi funguje správně v aktualizovaném přípravném prostředí.

  8. K prohození aktualizovaného a předehřátého staging slotu do produkčního prostředí použijte následující příkaz:

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

Zásadní změny mezi 3.x a 4.x

Níže jsou uvedené klíčové zásadní změny, které je potřeba vědět před upgradem aplikace 3.x na verzi 4.x, včetně zásadních změn specifických pro jazyk. Úplný seznam najdete v Azure Functions GitHub problémy označené Breaking Change: Approved.

Pokud váš programovací jazyk nevidíte, vyberte ho v horní části stránky.

Běhové prostředí

  • Azure Functions Proxies byla funkce ve verzích 1.x až 3.x modulu runtime Azure Functions. Tato funkce není ve verzi 4.x podporovaná. Další informace najdete v tématu Serverless REST API pomocí Azure Functions.

  • Protokolování do Azure Storage pomocí AzureWebJobsDashboard se už ve verzi 4.x nepodporuje. Místo toho byste měli použít Application Insights. (#1923)

  • Azure Functions 4.x teď vynucuje požadavky na verzi minimum pro rozšíření. Aktualizujte na nejnovější verzi ovlivněných rozšíření. Aktualizujte na bundl rozšíření verze 2.x nebo novější pro jazyky, které nejsou .NET. (#1987)

  • Výchozí a maximální časové limity se teď vynucují ve verzi 4.x pro aplikace funkcí běžící v Linuxu v plánu Consumption. (#1915)

  • Azure Functions 4.x používá Azure.Identity a Azure.Security.KeyVault.Secrets pro poskytovatele Key Vault a už nepoužívá použití Microsoft.Azure. KeyVault. Další informace o konfiguraci nastavení Function App naleznete v možnosti Key Vault v sekci Správa úložiště klíčů. (#2048)

  • ** Funkční aplikace, které sdílejí účty úložiště, se nyní nespustí, když jsou jejich ID hostitelů stejná. Další informace najdete v tématu Důležité informace o ID hostitele. (#2049)

  • Azure Functions 4.x podporuje novější verze .NET. Úplný seznam verzí najdete v tématu Podporované jazyky v Azure Functions.

  • InvalidHostServicesException je nyní kritická chyba. (#2045)

  • EnableEnhancedScopes je ve výchozím nastavení povolená. (#1954)

  • Odeberte HttpClient jako registrovanou službu. (#1911)

  • V Java 11 použijte jediný zavaděč tříd. (#1997)

  • Zastavte načítání pracovních souborů JAR v Java 8. (#1991)

  • Node.js verze 10 a 12 se v Azure Functions 4.x nepodporují. (#1999)

  • Serializace výstupu v Node.js aplikacích byla aktualizována tak, aby řešila předchozí nekonzistence. (#2007)

  • Výchozí počet vláken byl aktualizován. Může to mít vliv na funkce, které nejsou bezpečné pro přístup z více vláken nebo mají vysoké využití paměti. (#1962)

  • Python 3.6 se v Azure Functions 4.x nepodporuje. (#1999)

  • Ve výchozím nastavení je povolený sdílený přenos paměti. (#1973)

  • Výchozí počet vláken byl aktualizován. Může to mít vliv na funkce, které nejsou bezpečné pro přístup z více vláken nebo mají vysoké využití paměti. (#1962)

Další kroky

Další informace o verzích služby Functions

  • Last updated on