Sdílet prostřednictvím

Migrace aplikací ze služby Azure Functions verze 3.x na verzi 4.x

  • Článek

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 modulu runtime Functions najdete v přehledu verzí modulu runtime služby Azure Functions.

Důležité

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

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

Zvolte cílovou verzi .NET.

Ve verzi 3.x modulu runtime Functions cílí aplikace funkcí C# na .NET Core 3.1 pomocí modelu v procesu nebo rozhraní .NET 5 pomocí izolovaného pracovního modelu.

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í rozhraní .NET, které jsou podporovány funkcemi verze 4.x:

Verze .NET Oficiální typ zásad podpory .NET Modelprocesu funkcí 1,3
.NET 82 LTS Izolovaný model pracovního procesu
.NET 6 LTS (konec podpory 12. listopadu 2024) Model izolovaného pracovního procesu
Model v procesu3
.NET Framework 4.8 Zobrazit zásady Izolovaný model pracovního procesu

1 Izolovaný model pracovního procesu podporuje verze .NET (Long Term Support) a Standard Term Support (STS) a rozhraní .NET Framework. Model v procesu podporuje pouze verze LTS rozhraní .NET. Úplné porovnání funkcí a funkcí mezi těmito dvěma modely najdete v tématu Rozdíly mezi procesy a izolovaným pracovním procesem . NET Azure Functions.

2 .NET 8 se zatím v modelu v procesu nepodporuje, i když je k dispozici v izolovaném pracovním modelu. Informace o plánech .NET 8, včetně budoucích možností modelu v procesu, najdete v příspěvku aktualizace plánu služby Azure Functions.

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

Tip

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čuje se to, pokud se tomu dá 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ý pracovní model poskytne vaší aplikaci další výhody, včetně možnosti snadněji cílit na budoucí verze .NET. Pokud přecházíte na model izolovaného pracovního procesu, pomocník pro upgrade platformy .NET může také zpracovat řadu nezbytných změn kódu za vás.

Tato příručka neobsahuje konkrétní příklady pro .NET 6 v izolovaném pracovním modelu. Pokud potřebujete tuto verzi cílit, můžete přizpůsobit příklady izolovaného pracovního modelu .NET 8.

Příprava migrace

Pokud jste to ještě neudělali, pomocí Azure PowerShellu identifikujte seznam aplikací, které je potřeba migrovat v aktuálním předplatném Azure.

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ástrojů 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í přípravného slotu k otestování a ověření migrované aplikace v Azure na nové verzi modulu runtime. Pak můžete aplikaci nasadit s aktualizovaným nastavením verze do produkčního slotu. Další informace najdete v tématu Aktualizace pomocí slotů.
  6. Publikujte migrovaný projekt do aktualizované aplikace funkcí.

Když pomocí sady Visual Studio publikujete projekt verze 4.x do existující aplikace funkcí v nižší verzi, zobrazí se výzva k tomu, aby visual Studio během nasazování aktualizovalo aplikaci funkcí na verzi 4.x. 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á vaší cílové verzi .NET a požadovanému modelu procesu (v procesu nebo izolovanému pracovnímu procesu).

Tip

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

Soubor projektu

Následující příklad je .csproj soubor projektu, 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# a pokud vaše aplikace místo toho používá skript jazyka C# (.csx soubory), měli byste před pokračováním převést na projektový model .

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

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

  2. Nastavte hodnotu PropertyGroup.AzureFunctionsVersion do v4.

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

    <OutputType>Exe</OutputType>

  4. V sadě ItemGroup.PackageReference nahraďte odkaz na Microsoft.NET.Sdk.Functions balíček 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 Microsoft.Azure.WebJobs.* oborech názvů. 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, možná budete 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ů příkazů 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 triggeru HTTP dále v tomto článku.

Pokud jste to ještě neudělali, aktualizujte projekt tak, aby odkazovat 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
Trigger časovače Přidání
Microsoft.Azure.Functions.Worker.Extensions.Timer
Vazby služby Storage Nahradit
Microsoft.Azure.WebJobs.Extensions.Storage
with
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues a
Microsoft.Azure.Functions.Worker.Extensions.Tables
Vazby objektů blob Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Vazby front Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Vazby tabulek Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Tables
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Tables
Vazby databáze Cosmos Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
Nebo
Microsoft.Azure.WebJobs.Extensions.DocumentDB
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Vazby služby Service Bus Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Vazby služby Event Hubs Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.EventHubs
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Vazby Event Gridu Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.EventGrid
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Vazby služby SignalR Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.SignalRService
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Odolná služba Functions Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.DurableTask
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Odolná služba Functions
(Zprostředkovatel úložiště SQL)		 Nahrazení odkazů na
Microsoft.DurableTask.SqlServer.AzureFunctions
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Odolná služba Functions
(Zprostředkovatel úložiště Netherite)		 Nahrazení odkazů na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Vazby služby Sendgrid Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.SendGrid
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Vazby Kafka Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Kafka
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Vazby RabbitMQ Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Injektáž závislostí
a konfigurace spuštění		 Odebrání odkazů na
Microsoft.Azure.Functions.Extensions
(Izolovaný model pracovního procesu tuto funkci poskytuje ve výchozím nastavení.)

Úplný seznam rozšíření, která je potřeba vzít v úvahu, najdete v dokumentaci jednotlivých rozšíření k úplným pokynům k instalaci izolovaného modelu procesu. Nezapomeňte nainstalovat nejnovější stabilní verzi všech balíčků, na které cílíte.

Tip

Všechny změny verzí rozšíření během tohoto procesu můžou vyžadovat host.json aktualizaci souboru. 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. Další informace najdete v tématu Vazby služby Azure Service Bus pro Azure Functions.

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

Tip

Vaše aplikace může také záviset na typech sady 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 sady Azure SDK pro .NET, téměř všechny balíčky, pro které se jedná o formulář 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 odkaz odebrat Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore ze souboru projektu. Pokud ale chcete dosáhnout nejlepšího výkonu, a to i u funkcí s jinými typy triggerů, měli byste zachovat FrameworkReference ASP.NET Core.

Soubor Program.cs nahradí všechny soubory, které mají FunctionsStartup atribut, což je obvykle Startup.cs soubor. Na místech, kde by váš FunctionsStartup kód odkazoval IFunctionsHostBuilder.Services, můžete místo toho přidat příkazy v rámci .ConfigureServices() metody HostBuilder v souboru .Program.cs Další informaceoch Program.cs

Mezi výše uvedené výchozí Program.cs příklady patří nastavení integrace aplikačních Přehledy pro izolovaný model pracovního procesu. Ve svém Program.csnástroji musíte také nakonfigurovat veškeré filtrování protokolů, které by se mělo vztahovat na protokoly pocházející z kódu v projektu. V izolovaném modelu host.json pracovního procesu soubor řídí pouze události generované modulem runtime hostitele služby Functions. Pokud pravidla filtrování Program.csnenakonfigurujete, můžou se v telemetrii zobrazovat rozdíly na úrovních protokolu, které jsou k dispozici pro různé kategorie.

I když můžete registrovat vlastní zdroje konfigurace jako součást HostBuilderprojektu, mějte na paměti, že tyto zdroje se vztahují pouze na kód v projektu. Platforma vyžaduje také konfiguraci triggeru a vazby a tato konfigurace by měla být poskytována prostřednictvím nastavení aplikace, odkazů na key vault nebo funkcí odkazů na konfiguraci aplikací.

Jakmile přesunete všechno od jakéhokoli existujícího FunctionsStartupProgram.cs souboru do souboru, můžete odstranit FunctionsStartup atribut a třídu, na kterou byl použit.

local.settings.json soubor

Soubor local.settings.json se používá pouze při místním spuštění. Informace najdete v tématu Místní soubor 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.

host.json soubor

Soubor host.json nevyžaduje žádné změny. Pokud však vaše aplikace Přehledy konfiguraci v tomto souboru z projektu modelu v procesu, možná budete chtít provést další změny v 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 .NET API nebo rozdílech mezi procesem v procesu a izolovaným pracovním procesem. Následující tabulka označuje klíčové třídy .NET 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 využitím integrace ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (s využitím integrace ASP.NET Core)
FunctionsStartup (atribut) Místo toho se používá Program.cs Místo toho se používá Program.cs

V vazbách můžou být také rozdíly mezi názvy tříd. Další informace najdete v referenčních článcích pro 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ší změny, které možná budete muset provést v projektu.

Serializace JSON

Ve výchozím nastavení se izolovaný pracovní model používá 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 tyto pokyny.

Úrovně protokolů a filtrování Přehledy aplikací

Protokoly je možné odesílat do aplikace Přehledy z modulu runtime hostitele Functions i kódu ve vašem projektu. Umožňuje host.json konfigurovat pravidla pro protokolování hostitele, ale pro řízení protokolů pocházejících z kódu budete muset nakonfigurovat pravidla filtrování jako součást vašeho Program.cskódu . 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ástrojů 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í Javy podporovaných 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 nabízí validátor před upgradem, který vám pomůže identifikovat potenciální problémy při migraci vaší aplikace funkcí na verzi 4.x. Spuštění validátoru před upgradem:

  1. Na webu Azure Portal 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 v modulu runtime Functions verze 4.x, a to buď místně pomocí nástrojů Azure Functions Core Tools v4 , nebo pomocí přípravného slotu.

Aktualizace aplikace funkcí v Azure

Před publikováním migrovaného projektu 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 verzi 4.x, je nastavit FUNCTIONS_EXTENSION_VERSION nastavení aplikace na ~4 vaši 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 spouštění ve Windows musíte také povolit .NET 6.0, což vyžaduje verze 4.x modulu runtime.

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

.NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve 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.

Aktualizace pomocí slotů

Použití slotů nasazení je dobrým způsobem, jak aktualizovat aplikaci funkcí na modul 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í. Toto prohození vyžaduje nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v produkčním slotu. 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 zpracovat výpadek ú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. Potom můžete prohodit aktualizovanou verzi z přípravného slotu.

Rutina Update-AzFunctionAppSetting PowerShellu v současné době nepodporuje sloty. Musíte použít Azure CLI nebo Azure Portal.

  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 ve Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime v .NET 6:

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

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

    .NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve 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 projekt kódu vyžadoval, aby se všechny aktualizace spouštěly ve verzi 4.x, nasaďte tyto aktualizace do přípravného slotu.

  6. Před prohozením ověřte, že vaše aplikace funkcí 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

Minimální aktualizace výpadků

Pokud chcete minimalizovat výpadky v produkční aplikaci, můžete nastavení prohodit WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS z přípravného 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>

    Během doby mezi prohozením a obnovou verze modulu runtime při přípravném slotu se můžou zobrazit chyby z přípravného slotu. K této chybě může dojít, protože během WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 prohození dojde k odebrání FUNCTIONS_EXTENSION_VERSION nastavení v přípravné fázi. Bez nastavení verze je váš slot ve špatném stavu. Aktualizace verze v přípravném slotu hned po prohození by měla slot vrátit zpět do dobrého stavu a v případě potřeby zavolat vrácení změn zpět. 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 se oba sloty nastavily 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 ve Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime v .NET 6:

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

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

    .NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve 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 projekt kódu vyžadoval, aby se všechny aktualizace spouštěly ve verzi 4.x, nasaďte tyto aktualizace do přípravného slotu.

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

  8. K prohození aktualizovaného a předzbrojené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

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 tématu Problémy s GitHubem ve službě Azure Functions s popiskem Zásadní změna: Schváleno.

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

Šablona běhového prostředí

  • Proxy služby Azure Functions je starší funkce pro verze 1.x až 3.x modulu runtime Azure Functions. Podporu proxy serverů Functions je možné znovu povolit ve verzi 4.x, abyste mohli úspěšně aktualizovat aplikace funkcí na nejnovější verzi modulu runtime. Co nejdříve byste měli přepnout na integraci aplikací funkcí se službou Azure API Management. API Management vám umožní využívat ucelenější sadu funkcí pro definování, zabezpečení, správu a monetizaci vašich rozhraní API založených na službě Functions. Další informace najdete v tématu Integrace služby API Management. Informace o opětovném povolení podpory proxy serverů ve službě Functions verze 4.x najdete v tématu Opětovné povolení proxy serverů ve funkcích v4.x.

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

  • Azure Functions 4.x teď vynucuje minimální požadavky na verzi rozšíření. Aktualizujte na nejnovější verzi ovlivněných rozšíření. V případě non-.NET jazyků aktualizujte sadu rozšíření verze 2.x nebo novější. (#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 služby Key Vault a už nepoužívá Microsoft.Azure.KeyVault. Další informace o konfiguraci nastavení aplikace funkcí najdete v možnosti Key Vault v úložištích tajných kódů. (#2048)

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

  • Azure Functions 4.x podporuje .NET 6 v procesu a izolované aplikace.

  • InvalidHostServicesException je teď závažná chyba. (#2045)

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

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

  • Použijte zavaděč s jednou třídou v Javě 11. (#1997)

  • Ukončete načítání pracovních souborů JAR v Javě 8. (#1991)

  • Node.js verze 10 a 12 se ve službě 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)

  • Azure Functions 4.x nepodporuje Python 3.6. (#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