Azure Functions ランタイム バージョンの概要

現在、Azure Functions では、いくつかのバージョンのランタイム ホストがサポートされています。 次の表に、使用可能なバージョン、サポート レベル、いつ使用する必要があるかの詳細を示します。

Version サポート レベル 説明
4.x GA すべての言語の関数に推奨されるランタイム バージョン。このバージョンを使用して、.NET 6.0 および .NET Framework 4.8 で C# 関数を実行します
3.x GA すべての言語をサポートします。 .NET Core 3.1 および .NET 5.0 で C# 関数を実行するには、このバージョンを使用します。
2.x GA レガシ バージョン 2.x のアプリではサポートされません。 このバージョンはメンテナンス モードになっており、拡張機能は以降のバージョンでのみ提供されます。
1.x GA .NET Framework を使用する必要があり、Azure portal、Azure Stack Hub ポータル、または Windows コンピューター上のローカルでの開発のみをサポートする C# アプリに限りお勧めされます。 このバージョンはメンテナンス モードになっており、拡張機能は以降のバージョンでのみ提供されます。

重要

2022 年 12 月 3 日以降、Azure Functions ランタイムのバージョン 2.x と 3.x で実行される関数アプリはサポートされなくなります。 その前に、関数アプリをテスト、検証し、Functions ランタイムのバージョン 4.x に移行してください。 これらのランタイム バージョンのサポートが終了するのは、これらのランタイム バージョンで必要な .NET Core 3.1 のサポートが終了するためです。 この要件は、すべての Azure Functions ランタイムの言語に影響します。
.NET Framework が必要な C# 関数アプリのために、Functions バージョン 1.x は引き続きサポートされます。 .NET Framework 4.8 で C# 関数を実行するために、Functions 4.x でプレビュー サポートを現在利用できます。

この記事では、これらのバージョン間のいくつかの相違点、各バージョンを作成する方法、関数が実行されるバージョンの変更方法について詳細に説明します。

サポートのレベル

次の 2 つのレベルのサポートがあります。

  • 一般公開 (GA) - 完全にサポートされ、運用環境用に承認されています。
  • プレビュー - まだサポートされていませんが、今後 GA 状態に達すると想定されています。

Languages

関数アプリ内のすべての関数は、同じ言語を共有する必要があります。 アプリを作成するときに、関数アプリで関数の言語を選択しました。 関数アプリの言語は FUNCTIONS_WORKER_RUNTIME 設定に保持され、既存の関数がある場合は変更できません。

次の表は、各ランタイム バージョンでどのプログラミング言語が現在サポートされているかを示しています。

Language 1.x 2.x 3.x 4.x
C# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1)
GA (.NET 5.0)
GA (.NET 6.0)
プレビュー (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10、8) GA (Node.js 14、12、10) GA (Node.js 14)
GA (Node.js 16)
F# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1) GA (.NET 6.0)
Java 該当なし GA (Java 8) GA (Java 11、8) GA (Java 11、8)
PowerShell 該当なし GA (PowerShell Core 6) GA (PowerShell 7.0、Core 6) GA (PowerShell 7.0)
プレビュー (PowerShell 7.2)
Python 該当なし GA (Python 3.7、3.6) GA (Python 3.9、3.8、3.7、3.6) GA (Python 3.9、3.8、3.7)
TypeScript2 該当なし GA GA GA

1 ランタイム バージョン 2.x を対象とする .NET クラス ライブラリのアプリは、.NET Core 2.x 互換モードで .NET Core 3.1 で実行されます。 詳細については、Functions v2. x に関する考慮事項に関するページを参照してください。
2 JavaScript へのトランスパイリングによってサポートされます。

サポートされている言語バージョンの詳細については、言語固有の開発者ガイドに関する記事をご覧ください。
言語サポートの計画的な変更については、「Azure ロードマップ」を参照してください。

特定のバージョンで実行する

既定では、Azure portal および Azure CLI で作成された関数アプリはバージョン 4.x に設定されます。 このバージョンは必要に応じて変更できます。 ランタイムのバージョンを 1.x にダウングレードできるのは、関数アプリを作成してから関数を追加するまでの間のみです。 より新しいバージョンへの移行は、既存の関数が含まれているアプリでも許可されます。 既存の関数がアプリに含まれる場合は、より新しいランタイム バージョンに移行する前に、バージョン間の破壊的変更にご注意ください。 以下のセクションでは、バージョン間の変更について詳しく説明します。

ランタイムのメジャー バージョンを変更する前に、まず、最新のメジャー バージョンで実行されている別の関数アプリにデプロイして、既存のコードをテストする必要があります。 このテストは、アップグレード後に適切に実行されることを確認するのに役立ちます。 また、Functions ランタイムを含む、Azure Functions Core Tools のランタイム固有のバージョンを使用して、ローカルでコードを検証することもできます。

v2.x へのダウングレードはサポートされていません。 可能であれば、常に、サポートされている最新バージョンの Functions ランタイムでアプリを実行してください。

Azure でのアプリのバージョンの変更

Azure の公開アプリから使用される Functions ランタイムのバージョンは、FUNCTIONS_EXTENSION_VERSION アプリケーションの設定によって決まります。 次のランタイムのメジャー バージョン値がサポートされています。

ランタイム ターゲット
~4 4.x
~3 3.x
~2 2.x
~1 1.x

重要

他のアプリ設定の変更や関数のコード変更が必要になる可能性があるため、このアプリ設定を任意に変更しないでください。 その代わりに、メジャー バージョンのアップグレードを行う準備ができている場合に、Azure portal で関数アプリの [構成][関数のランタイム設定] タブでこの設定を変更する必要があります。

詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」を参照してください。

特定のマイナー バージョンに固定する

最新のメジャー バージョンで実行されているときに関数アプリで生じることがある問題を解決するには、アプリを特定のマイナー バージョンに一時的に固定する必要があります。 これにより、最新のメジャー バージョンでアプリが正しく実行されるようになります。 マイナー バージョンに固定する方法は、Windows と Linux で異なります。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」を参照してください。

古いマイナー バージョンは、定期的に Functions から削除されます。 特定の古いマイナー バージョンの削除などの、Azure Functions リリースに関する最新のニュースについては、Azure App Service のお知らせを観察してください。

バージョン ~2.0 に固定する

バージョン 2.x (~2) で実行されている .NET 関数アプリは、.Net Core 3 の長期サポート バージョンである .Net Core 3.1 で実行されるように、自動的にアップグレードされます。 .Net Core 3.1 で .NET 関数を実行すると、最新のセキュリティ更新プログラムと製品の機能強化を利用できます。

~2.0 に固定されている関数アプリは、引き続き .Net Core 2.2 で実行され、セキュリティやその他の更新プログラムを受信しなくなります。 詳細については、Functions v2. x に関する考慮事項に関するページを参照してください。

拡張機能の最小バージョン

バインディング拡張機能のバージョンと Functions ランタイムのバージョンの間に、技術的な相関関係はありません。 ただし、バージョン 4.x 以降、Functions ランタイムは、すべてのトリガーおよびバインディング拡張機能の最小バージョンを強制します。

パッケージが最低限必要なバージョンを満たしていないという警告が表示される場合は、その NuGet パッケージを、通常行うように最小バージョンに更新する必要があります。 Functions v4.x で使用される拡張機能の最小バージョン要件については、この構成ファイルをご覧ください。

C# スクリプトの場合、host.json 内の拡張機能バンドル参照を次のように更新してください。

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

拡張機能バンドルのバージョンと Functions ランタイムのバージョンの間に、技術的な相関関係はありません。 ただし、バージョン 4.x 以降、Functions ランタイムは、拡張機能バンドルの最小バージョンを強制します。

拡張機能バンドルのバージョンが最低限必要なバージョンを満たしていないという警告が表示される場合は、host.json 内の既存の拡張機能バンドル参照を次のように更新してください。

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

拡張機能バンドルの詳細については、「拡張機能バンドル」を参照してください。

3.x から 4.x への移行

Azure Functions バージョン 4.x は、バージョン 3.x との下位互換性が高くなっています。 多くのアプリでは、コードを大幅に変更することなく、4.x に安全にアップグレードされるはずです。 運用アプリでメジャー バージョンを変更するには、その前にローカルで Azure Functions Core Tools のバージョン 4.x を使用して、またはステージング スロットでアプリを十分にテストしてください。

既存のアプリのアップグレード

関数アプリをローカルで開発する場合は、ローカルのプロジェクト環境と、Azure で実行されている関数アプリの両方をアップグレードする必要があります。

ローカル プロジェクト

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

C# クラス ライブラリ アプリを .NET 6 および Azure Functions 4.x に更新するには、TargetFrameworkAzureFunctionsVersion を更新します。

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

アプリによって参照される NuGet パッケージも、必ず最新バージョンに更新する必要があります。 詳細については、「 重大な変更 」を参照してください。 具体的なパッケージは、関数をインプロセスとアウトプロセスのどちらで実行するかによって異なります。

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

Note

Node.js 10 と12 は、Azure Functions 4.x ではサポートされていません。

Note

PowerShell 6 は Azure Functions 4.x ではサポートされていません。

Note

Python 3.6 は Azure Functions 4.x ではサポートされていません。

Azure

アップグレード前の検証ツールを使用すると、関数アプリを 4.x に移行する際に発生する可能性のある問題を特定できます。 既存のアプリを移行する前に、次の手順に従って、検証ツールを実行します。

  1. Azure portal で関数アプリに移動します

  2. [問題の診断と解決] ブレードを開きます

  3. [一般的な問題またはツールを検索する] で、「関数 4.x アップグレード前の検証ツール」を入力して選択します

アプリをアップグレードできることを検証したら、移行のプロセスを開始できます。 スロットなしの移行スロットを使用した移行の各手順については、以下のサブセクションを参照してください。

注意

スロットを使用して移行を管理する場合は、"両方" のスロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS アプリケーション設定を "0" に設定する必要があります。 これにより、行うバージョン変更をスロット スワップ操作に含めることができます。 その後、ステージング (非運用) スロットをアップグレードでき、それからスワップを実行できます。

アプリを 3.x から 4.x に移行するには、次のようにします。

  • FUNCTIONS_EXTENSION_VERSION アプリケーションの設定を ~4 に設定します
  • Windows 関数アプリの場合のみnetFrameworkVersion 設定を使用して .NET 6.0 を有効にします
スロットなしの移行

次の Azure CLI または Azure PowerShell コマンドを使用して、スロットを介さずにサイトで直接このアップグレードを実行できます。

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

# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
スロットを使用した移行

次の Azure CLI コマンドを使用すると、デプロイ スロットを使用してこのアップグレードを実行できます。

最初に、運用スロットを WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 で更新します。 アプリが再起動を許容できる場合 (これは可用性に影響を与えます)、トラフィックが少ない可能性があるときに運用スロットで設定を直接更新することをお勧めします。 代わりにこの設定を適切な場所に入れ替えることを選択した場合は、スワップ後すぐにステージング スロットを更新する必要があります。 ステージングのみに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 が設定されている場合にスワップすると、ステージングの FUNCTIONS_EXTENSION_VERSION 設定が削除され、スロットが不適切な状態になります。 スワップの直後にステージング スロットをバージョンで更新すると、必要に応じて変更をロールバックできます。 ただし、このような状況では、スワップを元に戻す前に運用環境の設定を直接更新して WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を削除する準備をしておく必要が依然としてあります。

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

# OR

# Alternatively get production prepared with WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS via a swap
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# The swap actions should be accompanied with a version specification for the slot. You may see errors from staging during the time between these actions.
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 を構成したら、ステージング スロット内の他のすべてを構成してから、スワップを実行できます。

# Get staging configured with 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>
# Get staging configured with the new extension version
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

# Be sure to confirm that your staging environment is working as expected before swapping.

# Swap to migrate production to the new version
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 の問題を参照してください。 プレビュー期間中は、さらに多くの変更が予想されます。 更新については、App Service のお知らせを購読してください。

ランタイム

  • Azure Functions プロキシは、4.x ではサポートされなくなりました。 Azure API Management を使用することをお勧めします。

  • 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.IdentityAzure.Security.KeyVault.Secrets が使用され、Microsoft.Azure.KeyVault の使用は非推奨となりました。 関数アプリ設定の構成方法の詳細については、「シークレット リポジトリ」の Key Vault オプションを参照してください。 (#2048)

  • ストレージ アカウントを共有する関数アプリは、ホスト ID が同じ場合、起動に失敗するようになりました。 詳細については、「ホスト ID に関する考慮事項」を参照してください。 (#2049)

  • Azure Functions 4.x は、.NET 6 のインプロセスアプリと分離アプリをサポートしています。

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

  • PowerShell 6 は Azure Functions 4.x ではサポートされていません。 (#1999)

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

  • Python 3.6 は Azure Functions 4.x ではサポートされていません。 (#1999)

  • 共有メモリ転送は、既定で有効になっています。 (#1973)

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

2.x から 3.x への移行

Azure Functions バージョン 3.x は、バージョン 2.x との下位互換性が高くなっています。 多くのアプリでは、コードを変更することなく、3.x に安全にアップグレードできます。 3.x への移行をお勧めしますが、運用アプリでメジャー バージョンを変更する前に、広範囲なテストを実行してください。

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

2.x アプリを 3.x にアップグレードする前に、次の言語固有の変更点にご留意ください。

.NET クラス ライブラリ関数を実行する場合のバージョン間の主な違いは、.NET Core ランタイムです。 Functions バージョン 2.x は .NET Core 2.2 で実行されるように設計されており、バージョン 3.x は .NET Core 3.1 で実行されるように設計されています。

Note

.NET Core 2.2 のサポートに関する問題のため、バージョン 2 (~2) に固定された関数アプリは、基本的には .Net core 3.1 で実行されています。 詳細については、Functions v2.x 互換性モードに関するページを参照してください。

  • 1.x の context.done 経由で割り当てられた出力バインドまたは戻り値が、2.x 以降の context.bindings での設定と同じ動作をするようになりました。

  • タイマー トリガー オブジェクトはパスカル ケースではなくキャメル ケースです。

  • dataType バイナリが指定された、イベント ハブにトリガーされる関数の場合、string ではなく、binary の配列を受け取ります。

  • HTTP 要求ペイロードには context.bindingData.req 経由でアクセスできなくなりました。 引き続き入力パラメーター context.req としてアクセスできるほか、context.bindings でアクセスできます。

  • Node.js 8 はサポートが終了しており、3.x 関数では実行されません。

1.x からそれ以降のバージョンへの移行

最新のバージョンではなくバージョン 1.x のランタイムを使用するように記述された既存のアプリを移行することができます。 必要な変更の大部分は、.NET Framework 4.8 と .NET Core 間での C# API の変更など、言語ランタイムの変更に関連する変更です。 また、コードとライブラリが、選択した言語ランタイムと互換性があることを確認する必要があります。 最後に、以下で示すトリガー、バインド、および機能での変更にも注意してください。 最適な移行結果を得るために、新しいバージョンで新しい関数アプリを作成し、既存のバージョン 1.x の関数コードを新しいアプリに移植してください。

アプリ構成を手動で更新することで "インプレース" アップグレードすることが可能ですが、1.x から上位のバージョンへの移行には、いくつかの破壊的変更が含まれます。 たとえば、C# では、デバッグ オブジェクトが TraceWriter から ILogger に変更されています。 最新のバージョン 3.x のテンプレートに基づいて新しいバージョン 3.x プロジェクトを作成することで、更新された関数から始めます。

バージョン 1.x 後のトリガーとバインドの変更

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

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

バージョン 1.x 後の機能の変更

バージョン 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 トリガーを使用することもできます。

  • ホスト構成ファイル (host.json) は空か、文字列 "version": "2.0" が含まれる必要があります。

  • 監視を改善するために、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}

ローカルで開発されたアプリケーションのバージョン

関数アプリを次のように更新し、ターゲット バージョンをローカルで変更できます。

Visual Studio のランタイム バージョン

Visual Studio では、プロジェクトを作成するときにランタイムのバージョンを選択します。 Visual Studio 用の Azure Functions ツールは、ランタイムのメジャー バージョン 3 つをサポートしています。 デバッグ時と公開時には、プロジェクトの設定に基づいて正しいバージョンが使用されます。 バージョン設定は、.csproj ファイルの次のプロパティで定義されています。

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

.NET 分離プロセス関数を使用している場合は、ターゲット フレームワークとして net6.0 または net48 を選択することもできます。 net48 のサポートは現在プレビュー段階です。

Note

Azure Functions 4.x では、Microsoft.NET.Sdk.Functions 拡張機能を 4.0.0 以上にする必要があります。

Visual Studio で 2.x アプリを 3.x に更新する

2.x をターゲットにする既存の関数を開き、.csproj ファイルを編集し、上記の値を更新することで 3.x に移行できます。 Visual Studio では、プロジェクト メタデータに基づき、ランタイム バージョンがユーザーに代わって自動的に管理されます。 ただし、お使いのコンピューターでその Visual Studio で 3.x 用のテンプレートとランタイムが設定される前に 3.x アプリを作成していない場合にのみ可能です。 "プロジェクトで指定されたバージョンと一致する、利用可能な Functions ランタイムはありません" のようなエラーが表示されることがあります。最新のテンプレートとランタイムを取り込むには、新しい関数プロジェクトを作成する操作を進めます。 バージョンとテンプレートの選択画面に進んだら、Visual Studio で最新テンプレートの取得が完了するまで待ちます。 最新の .NET Core 3 テンプレートが利用できるようになり、表示されたら、バージョン 3.x 用に構成されているプロジェクトの実行とデバッグができます。

重要

バージョン 3.x 関数は、Visual Studio バージョン 16.4 以降を使用している場合にのみ、Visual Studio で開発できます。

VS Code と Azure Functions Core Tools

Azure Functions Core Tools は、コマンドラインの開発に使用されます。また、Visual Studio Code 用の Azure Functions 拡張機能からも使用されます。 バージョン 3.x に対して開発するには、Core Tools のバージョン 3.x をインストールします。 バージョン 2.x の開発には Core Tools のバージョン 2.x が必要です。他のバージョンも同様です。 詳細については、「Azure Functions Core Tools のインストール」を参照してください。

Visual Studio Code の開発の場合は、必要に応じてインストールされているツールのバージョンと一致するように azureFunctions.projectRuntime のユーザー設定を更新します。 この設定で、関数アプリの作成時に使用されるテンプレートと言語も更新されます。 ~3 でアプリを作成するには、azureFunctions.projectRuntime ユーザー設定を ~3 に更新します。

Azure Functions extension runtime setting

Maven および Java アプリ

ローカル実行に必要なコア ツールの 3.x バージョンをインストールすることで、Java アプリを 2.x から 3.x に移行できます。 バージョン 3.x でアプリが正しくローカル実行されることを確認したら、アプリの POM.xml ファイルを更新し、次の例のように、FUNCTIONS_EXTENSION_VERSION 設定を ~3 に変更します。

<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>~3</value>
        </property>
    </appSettings>
</configuration>

バインド

バージョン 2.x から、ランタイムでは、次の利点を提供する新しいバインド拡張モデルが使用されています。

  • サード パーティのバインド拡張のサポート。

  • ランタイムとバインドの分離。 この変更により、バインド拡張を個別にバージョン管理したり、解放したりできます。 たとえば、基になる SDK の新しいバージョンに依存する拡張のバージョンにアップグレードするよう選択できます。

  • より軽量な実行環境。ここでは、使用中のバインドのみがランタイムによって識別され、読み込まれます。

HTTP とタイマーのトリガーを除き、すべてのバインドを関数アプリ プロジェクトに明示的に追加するか、ポータルで登録する必要があります。 詳細については、「バインディング拡張機能を登録する」を参照してください。

各ランタイム バージョンでサポートされるバインドを次の表に示します。

この表は、Azure Functions のメジャー バージョンのランタイムでサポートされているバインディングを示しています。

種類 1.x 2.x 以降1 トリガー 入力 出力
Blob Storage
Azure Cosmos DB
Azure SQL (プレビュー)
Dapr3
Event Grid
Event Hubs
HTTP と Webhook
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 バージョン 2.x ランタイム以降では、HTTP と Timer を除くすべてのバインドを登録する必要があります。 「バインディング拡張機能を登録する」を参照してください。

2 トリガーは従量課金プランでサポートされていません。 ランタイム駆動のトリガーが必要です。

3 Kubernetes、IoT Edge、およびその他の自己ホスト型モードでのみサポートされます。

Function App タイムアウト期間

関数アプリのタイムアウト期間は、functionTimeout プロジェクト ファイルの functionTimeout プロパティによって定義されます。 次の表は、特定のプランの既定値と最大値 (分) を示しています。

プラン Default 最大1
従量課金プラン 5 10
Premium プラン 302 無制限
専用プラン 302 無制限

1 関数アプリのタイムアウト設定に関係なく、HTTP トリガー関数で要求に応答するためにかかる最大時間は 230 秒です。 これは、Azure Load Balancer の既定のアイドル タイムアウトによるものです。 より長い処理時間では、Durable Functions async pattern の使用を検討するか、実際の作業を遅らせて、即座に応答を返します
2 Functions Runtime バージョン 1.x のタイムアウトの既定値は "無制限" です。

次の手順

詳細については、次のリソースを参照してください。