Azure Functions バージョン 3.x からバージョン 4.x にアプリを移行する

[アーティクル]
04/08/2024

Azure Functions バージョン 4.x は、バージョン 3.x との下位互換性が高くなっています。ほとんどのアプリでは、コードを大幅に変更する必要なく、4.x に安全に移行されるはずです。 Functions ランタイムバージョンの詳細については、「Azure Functions ランタイムバージョンの概要」をご覧ください。

重要

2022 年 12 月 13 日より、Azure Functions ランタイムのバージョン 2.x と 3.x で実行されている関数アプリでは、延長サポートは終了しています。詳細については、廃止されたバージョンに関する記事を参照してください。

この記事では、Functions ランタイムのバージョン 4.x で実行するように関数アプリを安全に移行するプロセスについて説明します。プロジェクトの移行手順は言語によって異なるため、記事の上部にあるセレクターから開発言語を選んでください。

移行する関数アプリを特定する

次の PowerShell スクリプトを使用して、現在バージョン 2.x または 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

ターゲットの .NET バージョンを選択する

Functions ランタイムのバージョン 3.x では、C# 関数アプリはインプロセスモデルを使用して .NET Core 3.1 をターゲットにするか、分離ワーカーモデルを使用して .NET 5 をターゲットにします。

関数アプリを移行すると、.NET のターゲットバージョンを選択できます。 C# プロジェクトを Functions バージョン 4.x でサポートされている次のいずれかのバージョンの .NET に更新できます。

.NET バージョン	.NET 公式サポートポリシーのリリースの種類	Functions プロセスモデル^1、2
.NET 9	STS (2026 年 5 月 12 日にサポート終了)	分離ワーカーモデル
.NET 8	LTS (2026 年 11 月 10 日にサポート終了)	分離ワーカーモデル、インプロセスモデル²
.NET Framework 4.8	ポリシーを参照	分離ワーカーモデル

¹分離ワーカーモデルでは、.NET の長期サポート (LTS) と標準期間サポート (STS) の各バージョンと、.NET Framework がサポートされます。インプロセスモデルでは、.NET の LTS リリースのみがサポートされます (.NET 8 で終了)。 2 つのプロセスモデル間の完全な機能の比較については、インプロセスと分離ワーカープロセスの .NET Azure Functions の違いに関するページを参照してください。

² インプロセスモデルのサポートは、2026 年 11 月 10 日に終了します。詳細については、こちらのサポートに関するお知らせを参照してください。完全なサポートを受け続けるには、分離ワーカーモデルにアプリを移行する必要があります。

ヒント

分離ワーカーモデルでは .NET 8 に更新することをお勧めします。 .NET 8 は、.NET から最長のサポート期間を持つ完全にリリースされたバージョンです。

インプロセスモデルを代わりに使用することもできますが、回避できる場合は推奨されません。インプロセスモデルの場合は、サポートは 2026 年 11 月 10 日に終了するため、その前に分離ワーカーモデルに移行する必要があります。バージョン 4.x に移行する際にこれを行うことで、必要な作業の合計を減らすことができます。また、分離ワーカーモデルは、将来のバージョンの .NET をより簡単にターゲットにできるなど、アプリにさらなるベネフィットをもたらします。分離ワーカーモデルに移行する場合は、.NET アップグレードアシスタントで必要なコード変更の多くを自動的に処理することもできます。

このガイドでは、.NET 9 の具体的な例については説明しません。このバージョンを対象にする必要がある場合は、.NET 8 の分離ワーカーモデルの例を応用できます。

移行を準備する

まだ実行していない場合は、Azure PowerShell を使用して、現在の Azure サブスクリプションで移行する必要があるアプリの一覧を特定します。

Functions ランタイムのバージョン 4.x にアプリを移行する前に、次のタスクを実行する必要があります。

3.x から 4.x までの破壊的変更の一覧を確認します。
「ローカルプロジェクトを移行する」の手順を完了してローカルプロジェクトをバージョン 4.x に移行します。
プロジェクトを移行したら、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
Azure でホストされているアプリでアップグレード前検証ツールを実行し、特定された問題をすべて解決します。
Azure の関数アプリを新しいバージョンに更新します。ダウンタイムを最小限に抑える必要がある場合は、ステージングスロットを使用して、新しいランタイムバージョンで移行したアプリを Azure でテストおよび検証することを検討してください。その後、更新されたバージョン設定を使用してアプリを運用スロットにデプロイできます。詳細については、「スロットを使用した更新」を参照してください。
移行したプロジェクトを更新された関数アプリに発行します。

Visual Studio を使用してバージョン 4.x プロジェクトを下位バージョンの既存の関数アプリに発行する場合は、デプロイ時に Visual Studio で関数アプリをバージョン 4.x に更新するように求められます。この更新では、「スロットなしの更新」で定義されているのと同じプロセスが使用されます。

ローカルプロジェクトを移行する

アップグレード手順は言語によって異なります。目的の言語が表示されていない場合は、記事の上部にあるセレクターから選択します。

.NET のターゲットバージョンと目的のプロセスモデル (インプロセスまたは分離ワーカープロセス) に一致するタブを選択します。

ヒント

分離ワーカーモデルを使用して LTS または STS バージョンの .NET に移行する場合は、.NET アップグレードアシスタントを使用して、次のセクションで説明する多くの変更を自動的に行うことができます。

プロジェクトファイル

次の例は、バージョン 3.x で .NET Core 3.1 を使用する .csproj プロジェクトファイルです。

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

Functions バージョン 4.x で実行するようにこの XML ファイルを更新するには、次のいずれかの手順に従います。

以下の手順はローカル C# プロジェクトを想定しています。代わりに C# スクリプト (.csx ファイル) がアプリで使用されている場合、プロジェクトモデルに変換してから続行してください。

.csproj XML プロジェクトファイルには、次の変更を加える必要があります。

PropertyGroup の値を設定します。TargetFramework から net8.0。
PropertyGroup の値を設定します。AzureFunctionsVersion から v4。
次の OutputType 要素を PropertyGroup に追加します。
```
<OutputType>Exe</OutputType>
```

ItemGroup で。PackageReference リストで、Microsoft.NET.Sdk.Functions へのパッケージ参照を次の参照に置き換えます。

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

Microsoft.Azure.WebJobs.* 名前空間内の他のパッケージへの参照を書き留めます。これらのパッケージは後の手順で置き換えます。

次の新しい ItemGroup を追加します。

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

これらの変更を行うと、更新されたプロジェクトは次の例のようになります。

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

.csproj XML プロジェクトファイルには、次の変更を加える必要があります。

PropertyGroup の値を設定します。TargetFramework から net48。
PropertyGroup の値を設定します。AzureFunctionsVersion から v4。
次の OutputType 要素を PropertyGroup に追加します。
```
<OutputType>Exe</OutputType>
```

ItemGroup で。PackageReference リストで、Microsoft.NET.Sdk.Functions へのパッケージ参照を次の参照に置き換えます。

  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

Microsoft.Azure.WebJobs.* 名前空間内の他のパッケージへの参照を書き留めます。これらのパッケージは後の手順で置き換えます。

次の新しい ItemGroup を追加します。

<ItemGroup>
  <Folder Include="Properties\" />
</ItemGroup>

これらの変更を行うと、更新されたプロジェクトは次の例のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
      <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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

.csproj XML プロジェクトファイルには、次の変更を加える必要があります。

PropertyGroup の値を設定します。TargetFramework から net8.0。
PropertyGroup の値を設定します。AzureFunctionsVersion から v4。

既存の ItemGroup.PackageReference リストを次の ItemGroup に置き換えます。

<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
</ItemGroup>

これらの変更を行うと、更新されたプロジェクトは次の例のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

パッケージと名前空間の変更

移行先のモデルに基づいて、アプリケーションが参照するパッケージを更新または変更する必要がある場合があります。ターゲットパッケージを採用する場合は、using ステートメントの名前空間と参照する一部の型を更新する必要がある場合があります。これらの名前空間の変更が using ステートメントに及ぼす影響については、この記事で後ほど紹介する HTTP トリガーテンプレートの例で確認できます。

まだ更新していない場合、次に示すものの最新の安定バージョンを参照するようにプロジェクトを更新します。

アプリが使用するトリガーとバインドによっては、アプリは別のパッケージセットを参照する必要がある場合があります。次の表に、最も一般的に使用されるいくつかの拡張機能の置換を示します。

シナリオ	パッケージ参照の変更
タイマートリガー	追加 Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage のバインド	Replace `Microsoft.Azure.WebJobs.Extensions.Storage` with Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs、 Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues、 Microsoft.Azure.Functions.Worker.Extensions.Tables
BLOB のバインド	次の `Microsoft.Azure.WebJobs.Extensions.Storage.Blobs` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
キューのバインド	次の `Microsoft.Azure.WebJobs.Extensions.Storage.Queues` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
テーブルのバインド	次の `Microsoft.Azure.WebJobs.Extensions.Tables` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB のバインド	次の `Microsoft.Azure.WebJobs.Extensions.CosmosDB` および/または `Microsoft.Azure.WebJobs.Extensions.DocumentDB` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus のバインド	次の `Microsoft.Azure.WebJobs.Extensions.ServiceBus` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs のバインド	次の `Microsoft.Azure.WebJobs.Extensions.EventHubs` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid のバインド	次の `Microsoft.Azure.WebJobs.Extensions.EventGrid` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service のバインド	次の `Microsoft.Azure.WebJobs.Extensions.SignalRService` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions	次の `Microsoft.Azure.WebJobs.Extensions.DurableTask` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions (SQL ストレージプロバイダー)	次の `Microsoft.DurableTask.SqlServer.AzureFunctions` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions (Netherite ストレージプロバイダー)	次の `Microsoft.Azure.DurableTask.Netherite.AzureFunctions` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid のバインド	次の `Microsoft.Azure.WebJobs.Extensions.SendGrid` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka のバインド	次の `Microsoft.Azure.WebJobs.Extensions.Kafka` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ のバインド	次の `Microsoft.Azure.WebJobs.Extensions.RabbitMQ` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
依存関係の挿入とスタートアップ構成	次への参照を削除します `Microsoft.Azure.Functions.Extensions` (分離ワーカーモデルでは、この機能が既定で提供されます)

検討するべき拡張機能の全一覧については、「サポートされているバインド」を参照し、分離プロセスモデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。

ヒント

このプロセス中に拡張機能のバージョンを変更するとき、場合によっては、host.json ファイルの更新も必要になります。使用する各拡張機能のドキュメントを必ず読んでください。たとえば、Service Bus 拡張機能では、バージョン 4.x と 5.x の間で構造に破壊的変更があります。詳しくは、「Azure Functions の Azure Service Bus バインド」をご覧ください。

分離ワーカーモデルアプリケーションでは Microsoft.Azure.WebJobs.* 名前空間や Microsoft.Azure.Functions.Extensions 内のどのパッケージも参照するべきではありません。これらへの参照が何か残っている場合は、それらを削除する必要があります。

ヒント

アプリは、トリガーとバインドの一部として、またはスタンドアロンの依存関係として、Azure SDK の種類にも依存している場合があります。この機会を利用して、これらも同様に更新する必要があります。 Functions 拡張機能の最新バージョンは、Azure SDK for .NET (ほとんどすべてのパッケージの形式は Azure.* です) の最新バージョンで動作します。

まだ更新していない場合、次に示すものの最新の安定バージョンを参照するようにプロジェクトを更新します。

シナリオ	パッケージ参照の変更
タイマートリガー	追加 Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage のバインド	Replace `Microsoft.Azure.WebJobs.Extensions.Storage` with Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs、 Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues、 Microsoft.Azure.Functions.Worker.Extensions.Tables
BLOB のバインド	次の `Microsoft.Azure.WebJobs.Extensions.Storage.Blobs` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
キューのバインド	次の `Microsoft.Azure.WebJobs.Extensions.Storage.Queues` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
テーブルのバインド	次の `Microsoft.Azure.WebJobs.Extensions.Tables` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB のバインド	次の `Microsoft.Azure.WebJobs.Extensions.CosmosDB` および/または `Microsoft.Azure.WebJobs.Extensions.DocumentDB` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus のバインド	次の `Microsoft.Azure.WebJobs.Extensions.ServiceBus` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs のバインド	次の `Microsoft.Azure.WebJobs.Extensions.EventHubs` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid のバインド	次の `Microsoft.Azure.WebJobs.Extensions.EventGrid` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service のバインド	次の `Microsoft.Azure.WebJobs.Extensions.SignalRService` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions	次の `Microsoft.Azure.WebJobs.Extensions.DurableTask` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions (SQL ストレージプロバイダー)	次の `Microsoft.DurableTask.SqlServer.AzureFunctions` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions (Netherite ストレージプロバイダー)	次の `Microsoft.Azure.DurableTask.Netherite.AzureFunctions` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid のバインド	次の `Microsoft.Azure.WebJobs.Extensions.SendGrid` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka のバインド	次の `Microsoft.Azure.WebJobs.Extensions.Kafka` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ のバインド	次の `Microsoft.Azure.WebJobs.Extensions.RabbitMQ` への参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
依存関係の挿入とスタートアップ構成	次への参照を削除します `Microsoft.Azure.Functions.Extensions` (分離ワーカーモデルでは、この機能が既定で提供されます)

ヒント

Microsoft.NET.Sdk.Functions の最新の安定バージョンを参照するようにプロジェクトを更新します。

アプリが使用するトリガーとバインドによっては、アプリは追加のパッケージセットを参照する必要がある場合があります。検討するべき拡張機能の一覧については、「サポートされているバインド」を参照し、インプロセスプロセスモデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。

ヒント

Program.cs ファイル

分離ワーカープロセスで実行できるよう移行する場合は、次の 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();

この例には、パフォーマンスを向上させ、アプリで HTTP トリガーを使用するときに使い慣れたプログラミングモデルを提供するための ASP.NET Core 統合が含まれています。 HTTP トリガーを使用しない場合は、ConfigureFunctionsWebApplication の呼び出しを ConfigureFunctionsWorkerDefaults の呼び出しに置き換えることができます。それによって、プロジェクトファイルから Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore への参照を削除できます。ただし、最適なパフォーマンスを得るためには、他のトリガータイプを持つ関数の場合でも、ASP.NET Core への FrameworkReference を保持するべきです。

Program.cs ファイルで置換されるファイルに FunctionsStartup 属性がある場合は、通常は Startup.cs ファイルです。 FunctionsStartup コードが IFunctionsHostBuilder.Services を参照する場所で、代わりに HostBuilder の .ConfigureServices() メソッド内のステートメントを Program.cs に追加できます。 Program.cs の操作については、分離ワーカーモデルガイドの「スタートアップと構成」をご覧ください。

上記の既定の Program.cs の例には、分離ワーカーモデル用の Application Insights 統合のセットアップが含まれます。実際の Program.cs の中で、プロジェクト内のコードから受け取るログに適用する必要があるログのフィルター処理も構成する必要があります。分離ワーカーモデルにおいて、host.json ファイルが制御するのは、Functions ホストランタイムによって生成されたイベントだけです。 Program.cs でフィルター規則を構成しない場合、テレメトリのさまざまなカテゴリに対して異なるログレベルが表示される場合があります。

HostBuilder の一部としてカスタム構成ソースを登録することはできますが、これらが適用されるのも同様にプロジェクト内のコードに対してだけであることに注意してください。トリガーとバインドの構成はプラットフォームでも必要であり、これは、アプリケーション設定、Key Vault 参照、または App Configuration 参照機能を通して提供する必要があります。

既存の FunctionsStartup から Program.cs ファイルへすべてを移動すると、FunctionsStartup 属性と、それが適用されていたクラスを削除できます。

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .ConfigureServices(services => {
                    services.AddApplicationInsightsTelemetryWorkerService();
                    services.ConfigureFunctionsApplicationInsights();
                })
                .Build();
            host.Run();
        }
    }
}

既存の FunctionsStartup から Program.cs ファイルへすべてを移動すると、FunctionsStartup 属性と、それが適用されていたクラスを削除できます。

local.settings.json ファイル

local.settings.json ファイルは、ローカルで実行している場合にのみ使用されます。詳細については、「ローカル設定ファイル」を参照してください。

バージョン 4.x に移行するときは、local.settings.json ファイルに少なくとも次の要素が含まれていることを確認します。

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

Note

インプロセスの実行から分離ワーカープロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。

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

注意

インプロセスの実行から分離ワーカープロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1"
    }
}

Note

インプロセスモデルを使用して .NET 8 をターゲットにすることを選んだ場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet" に設定し、FUNCTIONS_INPROC_NET8_ENABLED 値を "1" に設定する必要があります。

host.json ファイル

host.json ファイルに変更は必要ありません。ただし、このファイル内の Application Insights 構成がインプロセスモデルプロジェクトからのものである場合、Program.cs ファイルに追加の変更を加える必要があるかもしれません。 host.json ファイルが制御するのは、Functions ホストランタイムからのログだけであり、分離ワーカーモデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。これらのログをフィルター処理する方法の詳細については、「分離ワーカーモデルでのログレベルの管理」を参照してください。

クラス名の変更

一部のキークラスは、バージョン間で名前が変更されました。これらの変更は、.NET API の変更、またはインプロセスと分離 worker プロセスの違いのいずれかの結果によるものです。次の表は、移行するときに変更される可能性がある、Functions によって使用されている主要な .NET クラスを示しています。

.NET Core 3.1	.NET 5	.NET 8
`FunctionName` (属性)	`Function` (属性)	`Function` (属性)
`ILogger`	`ILogger`	`ILogger`、`ILogger<T>`
`HttpRequest`	`HttpRequestData`	`HttpRequestData`、`HttpRequest` (ASP.NET Core 統合を使用)
`IActionResult`	`HttpResponseData`	`HttpResponseData`、`IActionResult` (ASP.NET Core 統合を使用)
`FunctionsStartup` (属性)	代わりに `Program.cs` を使用します	代わりに `Program.cs` を使用します

.NET Core 3.1	.NET 5	.NET Framework 4.8
`FunctionName` (属性)	`Function` (属性)	`Function` (属性)
`ILogger`	`ILogger`	`ILogger`、`ILogger<T>`
`HttpRequest`	`HttpRequestData`	`HttpRequestData`
`IActionResult`	`HttpResponseData`	`HttpResponseData`
`FunctionsStartup` (属性)	代わりに `Program.cs` を使用します	代わりに `Program.cs` を使用します

.NET Core 3.1	.NET 5	.NET 8 (インプロセス)
`FunctionName` (属性)	`Function` (属性)	`FunctionName` (属性)
`ILogger`	`ILogger`	`ILogger`
`HttpRequest`	`HttpRequestData`	`HttpRequest`
`IActionResult`	`HttpResponseData`	`IActionResult`
`FunctionsStartup` (属性)	代わりに `Program.cs` を使用します	`FunctionsStartup` (属性)

バインドにクラス名の違いがある場合もあります。詳細については、特定のバインドの参照記事を参照してください。

その他のコード変更

このセクションでは、移行を行う際に考慮する必要があるその他のコード変更に焦点を当てます。これらの変更はすべてのアプリケーションで必要なわけではありませんが、シナリオに関連があるかどうかを評価する必要があります。 3.x から 4.x の破壊的変更で、プロジェクトに加える必要があるその他の変更がないかを確認してください。

JSON シリアル化

既定では、分離ワーカーモデルは JSON シリアル化に System.Text.Json を使用します。シリアライザーオプションをカスタマイズしたり、JSON.NET (Newtonsoft.Json) に切り替えたりするには、こちらの手順を参照してください。

Application Insights のログレベルとフィルター処理

ログは、Functions ホストランタイムとプロジェクト内のコードの両方から Application Insights に送信できます。 host.json では、ホストログの規則を構成できますが、コードからのログを制御するには、Program.cs の一部としてフィルター規則を構成する必要があります。これらのログをフィルター処理する方法の詳細については、「分離ワーカーモデルでのログレベルの管理」を参照してください。

このセクションでは、移行を行う際に考慮する必要があるその他のコード変更について説明します。これらの変更はすべてのアプリケーションで必要なわけではありませんが、シナリオに関連があるかどうかを評価する必要があります。 3.x から 4.x の破壊的変更で、プロジェクトに加える必要があるその他の変更がないかを確認してください。

JSON シリアル化

Application Insights のログレベルとフィルター処理

HTTP トリガーテンプレート

インプロセスと分離ワーカープロセスの違いは、HTTP によってトリガーされる関数で確認できます。バージョン 3.x (インプロセス) の HTTP トリガーテンプレートは、次の例のようになります。

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

移行されたバージョンの HTTP トリガーテンプレートは、次の例のようになります。

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

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

プロジェクトを Azure Functions 4.x に更新するには、次の手順に従います。

Azure Functions Core Tools のローカルインストールをバージョン 4.x に更新します。
アプリの Azure Functions 拡張機能バンドルを 2.x 以上に更新します。詳細については、破壊的変更について参照してください。

必要に応じて、バージョン 4.x でサポートされている Java バージョンのいずれかに移動します。

次の例のように、アプリの POM.xml ファイルを更新して FUNCTIONS_EXTENSION_VERSION の設定を ~4 に変更します。

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

必要に応じて、バージョン 4.x でサポートされている Node.js バージョンのいずれかに移動します。

この機会に PowerShell 7.2 にアップグレードすることをお勧めします。詳細については、「PowerShell のバージョン」を参照してください。

Python 3.6 使用している場合は、いずれかのサポートされているバージョンに移行します。

アップグレード前検証コントロールを実行する

Azure Functions は、関数アプリを 4.x に移行するときに発生する可能性のある問題を特定するのに役立つアップグレード前検証コントロールを提供します。アップグレード前検証コントロールを実行するには、次の手順に従います。

Azure portal で関数アプリに移動します。
[問題の診断と解決] ページを開きます。
[関数アプリの診断] で、Functions 4.x Pre-Upgrade Validator の入力を開始し、一覧から選択します。
検証が完了したら、推奨事項を確認し、アプリの問題に対処します。アプリに変更を加える必要がある場合は、ローカルで Azure Functions Core Tools v4 を使用するか、ステージングスロットを使用して、Functions ランタイムのバージョン 4.x に対して変更を検証してください。

Azure で関数アプリを更新する

移行したプロジェクトを発行する前に、Azure の関数アプリホストのランタイムをバージョン 4.x に更新する必要があります。 Functions ホストで使用されるランタイムバージョンは FUNCTIONS_EXTENSION_VERSION アプリケーション設定によって制御されますが、場合によっては他の設定も更新する必要があります。コードの変更もアプリケーション設定の変更も、関数アプリを再起動する必要があります。

最も簡単な方法は、スロットなしで更新してから、アプリプロジェクトを再発行することです。また、スロットを使用して更新することで、アプリのダウンタイムを最小限に抑え、ロールバックを簡略化することもできます。

スロットなしで更新する

v4.x に更新する最も簡単な方法は、Azure の関数アプリで FUNCTIONS_EXTENSION_VERSION アプリケーション設定を ~4 に設定することです。スロットがあるサイトでは、別の手順に従う必要があります。

Azure CLI
Azure PowerShell

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

Update-AzFunctionAppSetting -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "~4"} -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME> -Force

別の設定も必要ですが、これは Windows と Linux とで異なります。

Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。

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

.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。

Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。

Set-AzWebApp -NetFrameworkVersion v6.0 -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>

.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。

また、特定の言語バージョンをターゲットにするために、linuxFxVersion サイト設定の更新が必要となる場合もあります。 linuxFxVersion の正しい値が既に設定されている場合は、この手順はスキップできます。詳細については、「有効な linuxFxVersion 値」を参照してください。

Functions 4.x 以前の Linux では、PowerShell アプリはサポートされていません。つまり、Linux で実行されている PowerShell 関数アプリはアップグレードの必要がないことを意味します。

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"

.NET Functions 分離ワーカープロセスに移行する場合は、--linux-fx-version に DOTNET-ISOLATED|6.0 か DOTNET-ISOLATED|7.0 を使用します。

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"

--linux-fx-version 値は、ターゲットの Java バージョンと一致している必要があります。

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"

--linux-fx-version 値は、ターゲットの Node.js バージョンと一致している必要があります。

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"

--linux-fx-version 値は、ターゲットの PowerShell バージョンと一致している必要があります。

この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソースグループの名前に置き換えます。

これで、バージョン 4.x で実行するように移行されたアプリプロジェクトを再発行できるようになりました。

スロットを使って更新する

デプロイスロットの使用は、関数アプリを以前のバージョンから v4.x ランタイムに更新するのに適しています。ステージングスロットを使用すると、ステージングスロットの新しいランタイムバージョンでアプリを実行し、検証後に運用環境に切り替えることができます。スロットは、更新中のダウンタイムを最小限に抑える方法も提供します。ダウンタイムを最小限に抑える必要がある場合は、「最小ダウンタイムの更新」の手順に従ってください。

更新されたスロットでアプリを確認したら、アプリと新しいバージョンの設定を運用環境に入れ替えられます。この入れ替えには、運用スロットでの WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 の設定が必要です。この設定をどのように追加するかで、更新に必要なダウンタイムの量に影響します。

標準的な更新

スロット対応関数アプリが完全再起動のダウンタイムを処理できる場合は、運用スロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を直接更新できます。運用スロットでこの設定を直接変更すると、可用性に影響する再起動が発生するため、トラフィックが減少した時点でこの変更を行うことを検討してください。その後、ステージングスロットから更新されたバージョンに入れ替えできます。

現在、Update-AzFunctionAppSetting PowerShell コマンドレットはスロットをサポートしていません。 Azure CLI または Azure portal を使用する必要があります。

運用スロットに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
```
この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソースグループの名前に置き換えます。このコマンドを実行すると、運用スロットで実行されているアプリが再起動します。

ステージングスロットにも WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS を設定するには、次のコマンドを使用します。

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

次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージングスロットを新しいランタイムバージョンに更新します。
```
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。
- Windows
- Linux
Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。
また、特定の言語バージョンをターゲットにするために、linuxFxVersion サイト設定の更新が必要となる場合もあります。 linuxFxVersion の正しい値が既に設定されている場合は、この手順はスキップできます。詳細については、「有効な linuxFxVersion 値」を参照してください。

Functions 4.x 以前の Linux では、PowerShell アプリはサポートされていません。つまり、Linux で実行されている PowerShell 関数アプリはアップグレードの必要がないことを意味します。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
.NET Functions 分離ワーカープロセスに移行する場合は、--linux-fx-version に DOTNET-ISOLATED|6.0 か DOTNET-ISOLATED|7.0 を使用します。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
--linux-fx-version 値は、ターゲットの Java バージョンと一致している必要があります。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
--linux-fx-version 値は、ターゲットの Node.js バージョンと一致している必要があります。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
--linux-fx-version 値は、ターゲットの PowerShell バージョンと一致している必要があります。
この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソースグループの名前に置き換えます。
コードプロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージングスロットにデプロイします。
入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。
更新されたステージングスロットを運用環境と入れ替えるには、次のコマンドを使用します。
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
```

最小ダウンタイムの更新

運用アプリのダウンタイムを最小限に抑えるには、ステージングスロットから運用環境に WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を入れ替えます。その後、事前に警告されたステージングスロットから更新されたバージョンに入れ替えできます。

ステージングスロットに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。

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

次のコマンドを使用して、スロットと新しい設定を運用環境で入れ替え、同時にステージングスロットのバージョン設定を復元します。
```
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>
```
入れ替えとステージング時のランタイムバージョンの復元の間に、ステージングスロットからエラーが表示される場合があります。このエラーは、入れ替え中にステージングに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 のみしかないと、ステージングの FUNCTIONS_EXTENSION_VERSION 設定が削除されるために発生する可能性があります。バージョン設定がないと、スロットの状態が正しくありません。入れ替えの直後にステージングスロットのバージョンを更新すると、スロットが適切な状態に戻り、必要に応じて変更をロールバックします。ただし、入れ替えのロールバックでは、ステージングで見られる運用環境で同じエラーが発生しないように、入れ替えを元に戻す前に運用環境から WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を直接削除する必要もあります。この運用環境設定の変更により、再起動が発生します。
ステージングスロットにもう一度 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。
```
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
この時点で、両方のスロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 が設定されています。
次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージングスロットを新しいランタイムバージョンに更新します。
```
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
```
Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。
- Windows
- Linux
Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。
```
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
```
.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。
また、特定の言語バージョンをターゲットにするために、linuxFxVersion サイト設定の更新が必要となる場合もあります。 linuxFxVersion の正しい値が既に設定されている場合は、この手順はスキップできます。詳細については、「有効な linuxFxVersion 値」を参照してください。

Functions 4.x 以前の Linux では、PowerShell アプリはサポートされていません。つまり、Linux で実行されている PowerShell 関数アプリはアップグレードの必要がないことを意味します。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"
```
.NET Functions 分離ワーカープロセスに移行する場合は、--linux-fx-version に DOTNET-ISOLATED|6.0 か DOTNET-ISOLATED|7.0 を使用します。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"
```
--linux-fx-version 値は、ターゲットの Java バージョンと一致している必要があります。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"
```
--linux-fx-version 値は、ターゲットの Node.js バージョンと一致している必要があります。
```
az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"
```
--linux-fx-version 値は、ターゲットの PowerShell バージョンと一致している必要があります。
この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソースグループの名前に置き換えます。
コードプロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージングスロットにデプロイします。
入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。
更新され、事前警告されたステージングスロットを運用環境と入れ替えるには、次のコマンドを使用します。
```
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
```

3.x と 4.x の間の破壊的変更

言語固有の破壊的変更を含め、3.x アプリを 4.x にアップグレードする前に注意すべき重要な破壊的変更を次に示します。完全な一覧については、破壊的変更: 承認済みに関する Azure Functions GitHub の問題を参照してください。

プログラミング言語が表示されていない場合は、ページ上部から選択してください。

ランタイム

Azure Functions プロキシは、Azure Functions ランタイムのバージョン 1.x から 3.x 用のレガシ機能です。 Functions プロキシのサポートは、バージョン 4.x で再度有効にすることができるため、関数アプリを最新のランタイムバージョンに正常に更新することができます。できるだけ早く、関数アプリと Azure API Management の統合に切り替える必要があります。 API Management では、Functions ベースの API の定義、セキュリティ保護、管理、収益化のためのより完全な機能セットを利用できます。詳しくは、「API Management 統合」をご覧ください。 Functions バージョン 4.x でプロキシのサポートを再度有効にする方法については、「Functions v4.x でプロキシを再度有効にする」を参照してください。
AzureWebJobsDashboard を使用した Azure Storage へのログ記録は、4.x ではサポートされなくなりました。その代わりに Application Insights を使用する必要があります。 (#1923)
Azure Functions 4.x では、拡張機能の最小バージョン要件が適用されるようになりました。影響を受ける拡張機能の最新バージョンに更新します。 .NET 以外の言語では、拡張機能バンドルバージョン 2.x 以降に更新してください。 (#1987)
従量課金プランにおいて Linux で実行される関数アプリの 4.x で、既定および最大のタイムアウトが適用されるようになりました。 (#1915)
Azure Functions 4.x では、Key Vault プロバイダーに Azure.Identity と Azure.Security.KeyVault.Secrets が使用され、Microsoft.Azure.KeyVault の使用は非推奨となりました。関数アプリ設定の構成方法の詳細については、「キー記憶域の管理」の Key Vault オプションを参照してください。 (#2048)
ストレージアカウントを共有する関数アプリは、ホスト ID が同じ場合、起動に失敗するようになりました。詳細については、「ホスト ID に関する考慮事項」を参照してください。 (#2049)

Azure Functions 4.x は、新しいバージョンの .NET をサポートしています。バージョンの詳細な一覧については、「Azure Functions でサポートされている言語」を参照してください。
InvalidHostServicesException は致命的なエラーになります。 (#2045)
EnableEnhancedScopes は既定で有効になっています。 (#1954)
登録済みサービスとして HttpClient を削除します。 (#1911)

Java 11 では、単一クラスローダーを使用します。 (#1997)
Java 8 では、ワーカー jar の読み込みを停止します。 (#1991)

Node.js のバージョン 10 と 12 は、Azure Functions 4.x ではサポートされていません。 (#1999)
以前の不整合に対処するために、Node.js アプリの出力シリアル化が更新されました。 (#2007)

既定のスレッド数が更新されました。スレッドセーフではない関数やメモリ使用量が多い関数は、影響を受ける可能性があります。 (#1962)

Python 3.6 は Azure Functions 4.x ではサポートされていません。 (#1999)
共有メモリ転送は、既定で有効になっています。 (#1973)
既定のスレッド数が更新されました。スレッドセーフではない関数やメモリ使用量が多い関数は、影響を受ける可能性があります。 (#1962)

次のステップ

Functions バージョンの詳細情報

次の方法で共有

Azure Functions バージョン 3.x からバージョン 4.x にアプリを移行する

移行する関数アプリを特定する

ターゲットの .NET バージョンを選択する

移行を準備する

ローカルプロジェクトを移行する

プロジェクトファイル

パッケージと名前空間の変更

Program.cs ファイル

local.settings.json ファイル

host.json ファイル

クラス名の変更

その他のコード変更

JSON シリアル化

Application Insights のログレベルとフィルター処理

JSON シリアル化

Application Insights のログレベルとフィルター処理

HTTP トリガーテンプレート

アップグレード前検証コントロールを実行する

Azure で関数アプリを更新する

スロットなしで更新する

スロットを使って更新する

標準的な更新

最小ダウンタイムの更新

3.x と 4.x の間の破壊的変更

ランタイム

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Functions バージョン 3.x からバージョン 4.x にアプリを移行する

移行する関数アプリを特定する

ターゲットの .NET バージョンを選択する

移行を準備する

ローカル プロジェクトを移行する

プロジェクト ファイル

パッケージと名前空間の変更

Program.cs ファイル

local.settings.json ファイル

host.json ファイル

クラス名の変更

その他のコード変更

JSON シリアル化

Application Insights のログ レベルとフィルター処理

HTTP トリガー テンプレート

アップグレード前検証コントロールを実行する

Azure で関数アプリを更新する

スロットなしで更新する

スロットを使って更新する

標準的な更新

最小ダウンタイムの更新

3.x と 4.x の間の破壊的変更

ランタイム

次のステップ

フィードバック

その他のリソース

ローカルプロジェクトを移行する

プロジェクトファイル

Application Insights のログレベルとフィルター処理

HTTP トリガーテンプレート