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

Důležité

Java nepodporuje modul runtime Azure Functions verze 1.x. Možná místo toho chcete migrovat vaši aplikaci Java z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.

Důležité

TypeScript nepodporuje modul runtime Azure Functions verze 1.x. Možná chcete migrovat aplikaci TypeScript z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.

Důležité

Azure Functions runtime verze 1.x nepodporuje PowerShell. Možná chcete migrovat aplikaci PowerShellu z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.

Důležité

Python nepodporuje modul runtime Azure Functions verze 1.x. Možná zvažujete migraci vaší aplikace Python z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.

Důležité

Support skončí pro verzi 1.x modulu runtime Azure Functions 14. září 2026. Důrazně doporučujeme migrovat aplikace na verzi 4.x podle pokynů v tomto článku.

Tento článek vás provede procesem bezpečné migrace vaší aplikace funkcí, aby běžela ve verzi 4.x prostředí 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.

Pokud modul runtime verze 1.x používáte v Azure Stack Hub, přečtěte si nejprve Úvahy pro Azure Stack Hub.

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

Spuštěním následujícího skriptu PowerShellu v Azure Cloud Shell vygenerujte seznam aplikací funkcí ve vašem předplatném, které aktuálně cílí na verzi 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

Pokud běžíte mimo Cloud Shell, musíte nejprve nastavit aktivní předplatné:

$Subscription = '<SUBSCRIPTION_ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

V tomto příkladu nahraďte '<SUBSCRIPTION_ID>' ID vašeho předplatného.

Volba cílové verze .NET

Ve verzi 1.x modulu runtime Functions cílí aplikace funkcí C# na rozhraní .NET Framework.

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íka
Model v procesu2
.NET Framework 4.8 Zobrazit zásady Izolovaný model pracovního procesu

1 Model isolated worker podporuje verze s dlouhodobou podporou (LTS) a standardní podporou (STS) pro .NET a .NET Framework. Model in-process podporuje pouze verze LTS .NET končící na .NET 8. Úplné porovnání funkcí a možností mezi těmito dvěma modely naleznete v tématu 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

Pokud vaše aplikace nezávisí jenom na knihovně nebo rozhraní API dostupné pro .NET Framework, doporučujeme aktualizovat na .NET 8 v izolovaném modelu pracovního procesu. Mnoho aplikací ve verzi 1.x cílí na .NET Framework pouze kvůli tomu, že to bylo dostupné, když byly vytvořeny. Další funkce jsou k dispozici pro novější verze .NET a pokud vaše aplikace není nucena zůstat v .NET Framework kvůli závislosti, měli byste cílit na novější verzi. .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ý 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 do izolovaného pracovního modelu, může pomocník pro upgrade .NET Upgrade Assistant 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 upravit příklady pro .NET 8.

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. Zkontrolujte seznam změn chování po verzi 1.x. Migrace z verze 1.x na verzi 4.x může také ovlivnit vazby.
  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. 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. 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ů.
  5. 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

Následující části popisují aktualizace, které musíte provést v souborech projektu jazyka C#, aby bylo možné spouštět v jedné z podporovaných verzí .NET ve functions verze 4.x. Zobrazené aktualizace jsou společné pro většinu projektů. Kód projektu může vyžadovat aktualizace, které nejsou uvedené v tomto článku, zejména při použití vlastních balíčků NuGet.

Migrace aplikace funkcí jazyka C# z verze 1.x na verzi 4.x modulu runtime Functions vyžaduje, abyste v kódu projektu udělali změny. Mnohé z těchto změn jsou výsledkem změn v jazyce C# a .NET rozhraní API.

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 pomocníka pro upgrade k automatickému provádění mnoha změn uvedených v následujících částech.

Projektový soubor

Následující příklad je .csproj soubor projektu, který běží na verzi 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>

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, možná budete muset aktualizovat nebo změnit balíčky, na které odkazuje vaše aplikace. Když přijmete cílové balíčky, musíte aktualizovat obor názvů v příkazech using a také 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 svůj 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řidání
Microsoft.Azure. Functions.Worker.Extensions.Timer
Úložiště vazby Nahradit
Microsoft.Azure.WebJobs.Extensions.Storage
s
Microsoft.Azure. Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues a
Microsoft.Azure.Functions.Worker.Extensions.Tables
Propojení 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
a/nebo
Microsoft.Azure.WebJobs.Extensions.DocumentDB
s nejnovější verzí
Microsoft.Azure. Functions.Worker.Extensions.CosmosDB
propojení 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
Vázání Event Grid 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
Durable Functions Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.DurableTask
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable 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
Durable 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í		 Odstranit odkazy na
Microsoft.Azure.Functions.Extensions
(Izolovaný model pracovního procesu tuto funkci poskytuje ve výchozím nastavení.)

Vizte Podporovaná propojení pro úplný seznam rozšíření, která je třeba zvažovat, a přečtěte si 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ékoliv změny verzí rozšíření během tohoto procesu mohou vyžadovat, abyste aktualizovali svůj host.json soubor. 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 Azure Service Bus vazby 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 na tyto odkazy máte 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í formát Azure.*.

Vazby Notification Hubs a Mobile Apps jsou podporovány pouze ve verzi 1.x modulu runtime. Při upgradu na verzi 4.x modulu runtime musíte tyto vazby odebrat a místo toho pracovat s těmito službami přímo pomocí jejich SDK.

Program.cs soubor

Ve většině případů migrace vyžaduje, abyste do projektu přidali 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, měli byste i u funkcí s jinými typy spouštěčů udržet FrameworkReference v prostředí 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ěče a vazby, která by se měla poskytovat 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 host.json

Nastavení v souboru host.json platí na úrovni aplikace funkcí místně i v Azure. Ve verzi 1.x je soubor host.json prázdný nebo obsahuje některá nastavení, která platí pro všechny funkce v aplikaci funkcí. Další informace najdete v tématu Host.json v1. Pokud soubor host.json obsahuje hodnoty nastavení, zkontrolujte případné změny ve formátu host.json v2.

Chcete-li spustit na verzi 4.x, musíte přidat "version": "2.0" do souboru host.json. Měli byste také zvážit přidání logging do konfigurace, jak je znázorněno v následujících příkladech:

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

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 .

soubor local.settings.json

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í. Ve verzi 1.x má soubor local.settings.json pouze dvě požadované hodnoty:

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

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.

Změny názvu třídy

Některé klíčové třídy změnily názvy mezi verzí 1.x a verzí 4.x. 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:

Verze 1.x .NET 8
FunctionName (atribut) Function (atribut)
TraceWriter ILogger<T>, ILogger
HttpRequestMessage HttpRequestData, HttpRequest (pomocí integrace ASP.NET Core)
HttpResponseMessage HttpResponseData, IActionResult (pomocí integrace ASP.NET Core)

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 změny chování po verzi 1.x a zjistit další změny, které možná budete muset provést 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.

Úroveň protokolů a filtrování v Application Insights

Protokoly je možné odesílat do Application Insights jak z modulu runtime hostitele Functions, tak i ze 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

Většina změn kódu mezi verzí 1.x a verzí 4.x se dá zobrazit ve funkcích aktivovaných protokolem HTTP. Šablona triggeru HTTP pro verzi 1.x vypadá jako v následujícím příkladu:

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

Šablona triggeru HTTP ve verzi 4.x 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. Přejděte na jednu z Node.js verzí podporovaných ve verzi 4.x.

  3. Přidejte do host.json oba prvky version a extensionBundle, aby to vypadalo jako v následujícím příkladu.

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

    Element extensionBundle je povinný, protože po verzi 1.x jsou vazby zachovány jako externí balíčky. Další informace najdete v tématu Balíčky rozšíření.

  4. Aktualizujte soubor local.settings.json tak, aby obsahuje alespoň následující prvky:

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

    Nastavení AzureWebJobsStorage může být emulátor úložiště Azurite nebo skutečný účet úložiště Azure. Další informace naleznete v tématu Emulátor místního úložiště.

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.

Aktualizace pomocí slotů

Použití nasazovacích slotů je dobrým způsobem, jak aktualizovat vaši aplikaci funkcí na prostředí 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 produktové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 snese výpadek způsobený úplným restartováním, můžete aktualizovat nastavení 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.

Cmdlet PowerShellu Update-AzFunctionAppSetting v současné době 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 fázovací slot na novou verzi 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 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 přepnutím se ujistěte, že vaše funkční aplikace funguje správně v aktualizovaném přípravném prostředí.

  7. K přepnutí 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 změnou a obnovou verze modulu runtime na přípravném slotu se můžou zobrazit chyby z tohoto slotu. K této chybě může dojít, protože během přesunu, který se uskuteční pouze v přípravném prostředí, dojde k odebrání nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 v přípravném prostředí. 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 můžete vrátit své změny 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 jsou oba sloty WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nastaveny.

  4. Pomocí následujícího příkazu změňte FUNCTIONS_EXTENSION_VERSION a aktualizujte fázovací slot na novou verzi 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 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 přepnutím se ujistěte, že vaše funkční aplikace 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

Změny chování po verzi 1.x

Tato část obsahuje podrobnosti o změnách provedených po verzi 1.x v chování triggerů i vazeb i v základních funkcích a chováních funkcí.

Změny triggerů a vazeb

Počínaje verzí 2.x musíte nainstalovat rozšíření pro konkrétní triggery a vazby používané funkcemi ve vaší aplikaci. Jedinou výjimkou pro tyto triggery HTTP a časovače, které nevyžadují rozšíření. Další informace naleznete v tématu Registrace a instalace rozšíření vazeb.

V function.json nebo atributech funkce mezi verzemi je také několik změn. Například vlastnost Event Hubs path je nyní eventHubName. Odkazy na dokumentaci pro každou vazbu najdete v existující tabulce vazeb.

Změny funkcí a funkčnosti

Několik funkcí bylo odebráno, aktualizováno nebo nahrazeno po verzi 1.x. Tato část podrobně popisuje změny, které se zobrazí v novějších verzích po použití verze 1.x.

Ve verzi 2.x byly provedeny následující změny:

  • Klíče pro volání koncových bodů HTTP se vždy ukládají zašifrované ve službě Azure Blob Storage. Ve verzi 1.x byly klíče ve výchozím nastavení uloženy v Azure Files. Když migrujete aplikaci z verze 1.x na verzi 2.x, stávající tajné kódy, které jsou v Azure Files, se resetují.

  • Modul runtime verze 2.x neobsahuje integrovanou podporu pro poskytovatele webhooků. Tato změna byla provedena kvůli zlepšení výkonu. Triggery HTTP můžete dál používat jako koncové body pro webhooky.

  • Ke zlepšení monitorování se řídicí panel WebJobs na portálu, který použil nastavení AzureWebJobsDashboard, nahradí nastavením Aplikace Azure Insights, který používá nastavení APPINSIGHTS_INSTRUMENTATIONKEY. Další informace najdete v tématu Monitor Azure Functions.

  • Všechny funkce v aplikaci funkcí musí sdílet stejný jazyk. Při vytváření aplikace funkcí musíte pro aplikaci zvolit zásobník modulu runtime. Zásobník modulu runtime je určen FUNCTIONS_WORKER_RUNTIME hodnotou v nastavení aplikace. Tento požadavek byl přidán, aby se zlepšila stopa a čas spuštění. Při místním vývoji musíte toto nastavení zahrnout také do souboru local.settings.json.

  • Výchozí časový limit pro funkce v plánu služby App Service se změní na 30 minut. Časový limit můžete ručně změnit zpět na neomezený pomocí nastavení functionTimeout v host.json.

  • Omezení souběžnosti HTTP se ve výchozím nastavení implementují pro funkce plánu Consumption s výchozím nastavením 100 souběžných požadavků na instanci. Toto chování můžete změnit v maxConcurrentRequests nastavení v souboru host.json.

  • Z důvodu omezení .NET Core, byla odebrána podpora funkcí skriptů F# (souborů .fsx). Kompilované funkce jazyka F# (.fs) se stále podporují.

  • Formát adresy URL triggerů event Gridu byl změněn tak, aby postupoval takto: https://{app}/runtime/webhooks/{triggerName}

  • Názvy některých předdefinovaných vlastních metrik se po verzi 1.x změnily. Duration byla nahrazena znakem MaxDurationMs, MinDurationMsa AvgDurationMs. Success Rate byl také přejmenován na Success Rate.

Důležité informace o Azure Stack Hub

App Service on Azure Stack Hub nepodporuje verzi 4.x Azure Functions. Při plánování migrace z verze 1.x v Azure Stack Hub můžete zvolit jednu z následujících možností:

  • Migrace na verzi 4.x hostovaná ve veřejném cloudu Azure Functions s využitím pokynů v tomto článku. Místo upgradu stávající aplikace byste vytvořili novou aplikaci s použitím verze 4.x a pak do ní nasadíte upravený projekt.
  • Přejděte na WebJobs hostovaný v plánu služby App Service v Azure Stack Hub.

Další kroky

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

  • Last updated on