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

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

重要

Azure Functions ランタイムのバージョン 1.x では、Java はサポートされていません。 Java アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、TypeScript はサポートされていません。 TypeScript アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、PowerShell はサポートされていません。 PowerShell アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、Python はサポートされていません。 Python アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions Runtime のバージョン 1.x のサポートは 2026 年 9 月 14 日に終了します。この記事の手順に従って、アプリをバージョン 4.x に移行することを強くお勧めします。

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

Azure Stack Hub でバージョン 1.x のランタイムを実行している場合は、最初に「Azure Stack Hub の考慮事項」を参照してください。

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

次の PowerShell スクリプトを使用して、現在バージョン 1.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 '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

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

Functions ランタイムのバージョン 1.x では、C# 関数アプリは .NET Framework をターゲットとします。

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

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

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

² .NET 8 はインプロセスモデルではまだサポートされていませんが、分離ワーカーモデルでは使用できます。インプロセスモデルの今後のオプションを含む .NET 8 プランの詳細については、Azure Functions ロードマップの更新の投稿を参照してください。

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

ヒント

アプリが .NET Framework でのみ使用できるライブラリまたは API に依存していない限り、分離ワーカーモデルで .NET 8 に更新することをお勧めします。 バージョン 1.x の多くのアプリでは、それらが作成されたときに使用可能だったため、.NET Framework のみをターゲットとしています。より新しいバージョンの .NET では追加の機能を使用できます。アプリで依存関係を理由とした .NET Framework の維持が強制されない場合は、最新のバージョンをターゲットにする必要があります。 .NET 8 は、.NET から最長のサポート期間を持つ完全にリリースされたバージョンです。

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

このガイドでは、分離ワーカーモデルでの .NET 7 または .NET 6 の具体的な例については説明しません。これらのバージョンをターゲットにする必要がある場合は、.NET 8 の分離ワーカーモデルの例を適応させることができます。

移行を準備する

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

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

バージョン 1.x の後に加えられた動作の変更一覧を確認します。バージョン 1.x からバージョン 4.x に移行すると、バインディングにも影響する可能性があります。
「ローカルプロジェクトを移行する」の手順を完了してローカルプロジェクトをバージョン 4.x に移行します。
プロジェクトを移行したら、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
Azure の関数アプリを新しいバージョンに更新します。ダウンタイムを最小限に抑える必要がある場合は、ステージングスロットを使用して、新しいランタイムバージョンで移行したアプリを Azure でテストおよび検証することを検討してください。その後、更新されたバージョン設定を使用してアプリを運用スロットにデプロイできます。詳細については、「スロットを使用した更新」を参照してください。
移行したプロジェクトを更新された関数アプリに発行します。

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

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

以下のセクションでは、Functions バージョン 4.x でサポートされる .NET のいずれかのバージョンで実行するために、C# プロジェクトファイルに加える必要がある更新について説明します。記載されている更新は、ほとんどのプロジェクトに共通するものです。特にカスタム NuGet パッケージを使っている場合、この記事に記載されていない更新がプロジェクトコードに必要になる場合があります。

C# 関数アプリを Functions ランタイムのバージョン 1.x からバージョン 4.x に移行するには、プロジェクトコードを変更する必要があります。これらの変更の多くは、C# 言語と .NET API が変更された結果によるものです。

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

ヒント

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

プロジェクトファイル

次の例は、バージョン 1.x で動作する .csproj プロジェクトファイルです。

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

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 から net6.0。
PropertyGroup の値を設定します。AzureFunctionsVersion から v4。

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

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

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

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </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 の最新の安定バージョンを参照するようにプロジェクトを更新します。

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

ヒント

Notification Hubs と Mobile Apps のバインディングは、ランタイムのバージョン 1.x でのみサポートされています。ランタイムのバージョン 4.x にアップグレードする場合は、SDK を使ってこれらのサービスを直接操作するために、これらのバインディングを削除する必要があります。

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 コア統合が含まれています。 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 属性と、それが適用されていたクラスを削除できます。

host.json ファイル

host.json ファイルの設定は、ローカルと Azure のいずれでも、関数アプリレベルで適用されます。バージョン 1.x では、host.json ファイルは空であるか、関数アプリ内のすべての関数に適用されるいくつかの設定が含まれています。詳細については、「Host.json v1」を参照してください。 host.json ファイルに設定値がある場合は、変更点がないか、host.json v2 の形式を確認します。

バージョン 4.x 上で実行するには、host.json ファイルに "version": "2.0" を追加する必要があります。また、次の例のように、構成に logging を追加することを検討してください。

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

host.json ファイルは、Functions ホストランタイムからのログのみを制御し、分離ワーカーモデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。これらのログをフィルター処理する方法の詳細については、「分離ワーカーモデルでのログレベルの管理」を参照してください。

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

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

local.settings.json ファイル

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

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

バージョン 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"
    }
}

クラス名の変更

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

バージョン 1.x	.NET 8
`FunctionName` (属性)	`Function` (属性)
`TraceWriter`	`ILogger<T>`、`ILogger`
`HttpRequestMessage`	`HttpRequestData`、`HttpRequest` (ASP.NET Core 統合を使用)
`HttpResponseMessage`	`HttpResponseData`、`IActionResult` (ASP.NET Core 統合の使用)

バージョン 1.x	.NET Framework 4.8
`FunctionName` (属性)	`Function` (属性)
`TraceWriter`	`ILogger<T>`、 `ILogger`
`HttpRequestMessage`	`HttpRequestData`
`HttpResponseMessage`	`HttpResponseData`

バージョン 1.x	.NET 6 (インプロセス)
`FunctionName` (属性)	`FunctionName` (属性)
`TraceWriter`	`ILogger<T>`、`ILogger`
`HttpRequestMessage`	`HttpRequest`
`HttpResponseMessage`	`IActionResult`

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

その他のコード変更

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

JSON シリアル化

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

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

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

JSON シリアル化

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

HTTP トリガーテンプレート

バージョン 1.x とバージョン 4.x の間のコード変更のほとんどは、HTTP トリガー関数に見られます。バージョン 1.x の HTTP トリガーテンプレートは、次の例のようになります。

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

バージョン 4.x の 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;
        }
    }
}

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

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

Azure Functions Core Tools のローカルインストールをバージョン 4.x に更新します。
バージョン 4.x でサポートされている Node.js バージョンのいずれかに移動します。
host.json に version と extensionBundle の両方の要素を追加し、次の例のようにします。
```
{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}
```
バージョン 1.x の後では、バインディングは外部パッケージとして維持されるため、extensionBundle 要素は必須です。詳細については、拡張機能のバンドルに関する記事を参照してください。
local.settings.json ファイルを更新して、少なくとも次の要素が含まれるようにします。
```
{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}
```
AzureWebJobsStorage 設定は、Azurite ストレージエミュレーターまたは実際の Azure Storage アカウントのいずれかにすることができます。詳細については、ローカルストレージエミュレーターに関するページを参照してください。

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

バージョン 1.x の後に加えられた動作の変更

このセクションでは、トリガーとバインディングの両方の動作とコア Functions の機能と動作の点で、バージョン 1.x の後に加えられた変更について詳しく説明します。

トリガーとバインドでの変更

バージョン 2.x 以降では、アプリの関数で使用される特定のトリガーとバインドの拡張機能をインストールする必要があります。この例外は、拡張機能を必要としない HTTP トリガーとタイマートリガーのみです。詳細については、バインド拡張機能の登録とインストールに関するページを参照してください。

バージョン間には、関数の function.json や属性の変更もいくつかあります。たとえば、Event Hubs の path のプロパティは eventHubName になりました。各バインドのドキュメントへのリンクについては、既存のバインド一覧を参照してください。

機能の変更

バージョン 1.x 後、いくつかの機能が削除、更新、置換されました。このセクションでは、バージョン 1.x の後に後続のバージョンを使用した場合に気づく変更点について詳しく説明します。

バージョン 2.x では次の点が変更されました。

HTTP エンドポイントを呼び出すキーは、Azure Blob Storage 内で常に暗号化されて格納されます。バージョン 1.x では、既定で Azure Files にキーが格納されていました。アプリをバージョン 1.x からバージョン 2.x に移行すると、Azure Files 内の既存のシークレットはリセットされます。
バージョン 2.x ランタイムには、Webhook プロバイダーの組み込みサポートは含まれていません。この変更はパフォーマンスを向上するために行われました。 Webhook のエンドポイントとして HTTP トリガーを使用することもできます。
監視を改善するために、AzureWebJobsDashboard 設定を使用したポータルの WebJobs ダッシュボードは、APPINSIGHTS_INSTRUMENTATIONKEY 設定を使用する Azure Application Insights に置き換えられています。詳しくは、「Azure Functions を監視する」をご覧ください。
関数アプリ内のすべての関数は、同じ言語を共有する必要があります。関数アプリを作成するときに、そのアプリのランタイムスタックを選択する必要があります。ランタイムスタックは、アプリケーション設定の FUNCTIONS_WORKER_RUNTIME 値によって指定されます。メモリ占有領域と起動時間を改善するために、この要件が追加されました。ローカルで開発する場合は、この設定も local.settings.json ファイルに含める必要があります。
App Service プランでの関数に対する既定のタイムアウトは 30 分に変更されます。 host.json の functionTimeout 設定を使用して、手動でタイムアウトを無制限に変更することができます。
従量課金プラン機能の場合、HTTP 同時実行のスロットルは既定で実装され、インスタンスあたりの既定の同時要求数は 100 です。この動作は host.json ファイルの maxConcurrentRequests 設定で変更できます。
.NET Core の制限があるため、F# スクリプト (.fsx ファイル) 関数のサポートが削除されました。コンパイル済みの F# 関数 (.fs) は引き続きサポートされます。
Event Grid トリガー Webhook の URL 形式は、次のパターンに従うように変更されました: https://{app}/runtime/webhooks/{triggerName}。
一部の事前定義済みカスタムメトリックの名前はバージョン 1.x の後に変更されました。 Duration は MaxDurationMs、MinDurationMs、AvgDurationMs に置き換えられました。 Success Rate の名前も Success Rate に変更されました。

Azure Stack Hub に関する考慮事項

Azure Stack Hub 上のApp Serviceでは、バージョン 4.x の Azure Functions はサポートされていません。 Azure Stack Hub でバージョン 1.x からの移行を計画している場合は、次のいずれかのオプションを選択できます:

この記事の手順に従って、パブリッククラウド Azure Functions でホストされているバージョン 4.x に移行します。既存のアプリをアップグレードする代わりに、バージョン 4.x を使用して新しいアプリを作成し、変更したプロジェクトをそれにデプロイします。
Azure Stack Hub の App Service プランでホストされている WebJobsに切り替えます。

次のステップ

Functions バージョンの詳細情報

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

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

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

移行を準備する

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

プロジェクト ファイル

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

Program.cs ファイル

host.json ファイル

local.settings.json ファイル

クラス名の変更

その他のコード変更

JSON シリアル化

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

HTTP トリガー テンプレート

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

スロットなしで更新する

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

標準的な更新

最小ダウンタイムの更新

バージョン 1.x の後に加えられた動作の変更

トリガーとバインドでの変更

機能の変更

Azure Stack Hub に関する考慮事項

次のステップ

その他のリソース

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

プロジェクトファイル

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

HTTP トリガーテンプレート