Visual Studio を使用する Azure Functions の開発

2025-09-23

Visual Studio には、C# クラスライブラリ関数を開発、テスト、および Azure にデプロイする方法が用意されています。このエクスペリエンスが Azure Functions を初めて使用する場合は、 Azure Functions の概要を参照してください。

すぐに始めるには、Visual Studio での関数のクイックスタートを最後まで行うことをお勧めします。

この記事では、Visual Studio を使用して C# クラスライブラリ関数を開発し、Azure に発行する方法について詳しく説明します。 C# クラスライブラリ関数を開発するための 2 つのモデルがあります。分離ワーカーモデルとインプロセスモデルです。

この記事は分離型ワーカーモデルバージョンをお読みいただいています。記事の上部にある任意のモデルを選択できます。

この記事のインプロセスモデルバージョンをお読みください。記事の上部にある任意のモデルを選択できます。

重要

インプロセスモデルのサポートは、2026 年 11 月 10 日に終了します。分離された worker モデルにアプリを移行することをお勧めします。

特に明記されていない限り、ここで示す手順と例は Visual Studio 2022 のものです。 Visual Studio 2022 リリースの詳細については、リリースノートまたはプレビューリリースノートを参照してください。

前提条件

Azure の開発ワークロードを含む Visual Studio 2022。
Azure Storage アカウントなど、他の必要なリソースは、発行プロセス中にサブスクリプションに作成されます。
Azure アカウントをお持ちでない場合は、開始する前に無料アカウントを作成してください。

Azure Functions プロジェクトを作成する

Visual Studio の Azure Functions プロジェクトテンプレートを使用すると、Azure の関数アプリに発行できる C# クラスライブラリプロジェクトを作成できます。関数アプリを使用すると、リソースの管理、デプロイ、スケーリング、および共有を容易にするための論理ユニットとして関数をグループ化できます。

Visual Studio メニューで、[ファイル]>[新規]>[プロジェクト] を選択します。
[ 新しいプロジェクトの作成 ] ダイアログで、検索ボックスに関数を入力し、 Azure Functions テンプレートを選択して、[ 次へ] を選択します。
[ 新しいプロジェクトの構成 ] ダイアログで、[ プロジェクト名] にプロジェクトの名前を入力し、[ 次へ] を選択します。関数アプリ名は、C# 名前空間として有効である必要があります。そのため、アンダースコア、ハイフン、その他の英数字以外の文字は使用しないでください。

[ 追加情報 ] ダイアログで、次の表に示すアクションを実行します。

設定	アクション	説明
関数ワーカー	[.NET 8.0 Isolated (Long Term Support)]$.NET 8.0 分離 (長期サポート)$ を選択します。	Visual Studio は、分離されたワーカープロセスで実行される関数プロジェクトを作成します。分離ワーカープロセスでは、長期サポート (LTS) を提供しない他のバージョンの .NET および .NET Framework もサポートされます。詳細については、「Azure Functions ランタイムバージョンをターゲットにする方法」をご覧ください。
Function	[Http トリガー] を選択します。	Visual Studio は、HTTP 要求によってトリガーされる関数を作成します。
ランタイムストレージアカウントに Azurite を使用する (AzureWebJobsStorage)	このチェックボックスをオンにします。	Azure の関数アプリにはストレージアカウントが必要であるため、プロジェクトを Azure に発行する際に割り当てられるか、作成されます。 HTTP トリガーでは、ストレージアカウントの接続文字列は使用されません。その他のすべてのトリガーの種類には、有効なストレージアカウント接続文字列が必要です。
承認レベル	[ 匿名] を選択します。	この承認設定を使用すると、任意のクライアントがキーを指定せずに作成された関数をトリガーできます。この構成により、新しい関数を簡単にテストできます。詳細については、「認可レベル」を参照してください。

設定	アクション	説明
関数ワーカー	.NET 8.0 インプロセス (長期サポート) を選択します。	Visual Studio では、Functions ランタイムのバージョン 4.x を使用してインプロセスで実行される関数プロジェクトが作成されます。詳細については、「Azure Functions ランタイムバージョンをターゲットにする方法」をご覧ください。
Function	[Http トリガー] を選択します。	Visual Studio は、HTTP 要求によってトリガーされる関数を作成します。
ランタイムストレージアカウントに Azurite を使用する (AzureWebJobsStorage)	このチェックボックスをオンにします。	Azure の関数アプリにはストレージアカウントが必要であるため、プロジェクトを Azure に発行する際に割り当てられるか、作成されます。 HTTP トリガーでは、ストレージアカウントの接続文字列は使用されません。その他のすべてのトリガーの種類には、有効なストレージアカウント接続文字列が必要です。
承認レベル	匿名の選択	この承認設定を使用すると、任意のクライアントがキーを指定せずに作成された関数をトリガーできます。この構成により、新しい関数を簡単にテストできます。詳細については、「認可レベル」を参照してください。

[承認レベル] を [匿名] に設定していることを確認します。関数 の既定のレベルを選択した場合は、関数エンドポイントにアクセスするための要求で関数キーを提示する必要があります。

[作成] を選択して、関数プロジェクトと HTTP トリガー関数を作成します。

Functions プロジェクトを作成すると、プロジェクトテンプレートによって C# プロジェクトが作成され、 Microsoft.Azure.Functions.Worker がインストールされ、NuGet パッケージが Microsoft.Azure.Functions.Worker.Sdk され、ターゲットフレームワークが設定されます。

Functions プロジェクトを作成すると、プロジェクトテンプレートによって C# プロジェクトが作成され、 Microsoft.NET.Sdk.Functions NuGet パッケージがインストールされ、ターゲットフレームワークが設定されます。

新しいプロジェクトには次のファイルが含まれます。

host.json: このファイルは、Functions ホストを構成するための方法を提供します。これらの設定は、ローカルでの実行時と Azure での実行時の両方に適用されます。詳細については、host.json reference のリファレンスを参照してください。
local.settings.json: このファイルは、関数をローカルで実行するときに使用する設定を保持します。これらの設定は、アプリが Azure で実行されるときに使用されません。詳細については、「アプリ設定をローカルで操作する」を参照してください。

重要

local.settings.json ファイルにはシークレットを含めることができるため、プロジェクトソース管理から除外する必要があります。このファイルの [プロパティ ] ダイアログで、[ 出力ディレクトリにコピー ] 設定が [新しい場合はコピー] に設定されていることを確認します。

詳細については、分離ワーカーガイドのプロジェクト構造を参照してください。

詳細については、「関数クラスライブラリプロジェクト」を参照してください。

ローカルでアプリの設定を操作する

関数アプリが Azure で実行されると、関数に必要な設定がアプリ設定に暗号化されて格納されます。ローカル開発時に、これらの設定は代わりにlocal.settings.jsonファイルのValues コレクションに追加されます。 local.settings.json ファイルには、ローカル開発ツールで使用される設定も格納されます。

プロジェクトの Valuesのコレクション内の項目は、Azure の関数アプリのアプリケーション設定の項目をミラー化するためのものです。

Visual Studio では、プロジェクトを発行するときに 、local.settings.json の設定は自動的にアップロードされません。これらの設定が Azure の関数アプリにも確実に存在するようにするには、プロジェクトを発行した後にそれらをアップロードします。詳細については、「Function App の設定」を参照してください。 ConnectionStrings コレクション内の値は発行されません。

コードを使用して、関数アプリの設定値を環境変数として読み取ることもできます。詳細については、「環境変数」を参照してください。

ローカル開発用のプロジェクトを構成する

Functions ランタイムは、ストレージアカウントを内部的に使用します。開発中は、この内部アカウントに対して有効なストレージアカウントを使用することも、 Azurite エミュレーターを使用することもできます。

HTTP および webhook 以外のすべてのトリガーの種類について、Values.AzureWebJobsStorage キーの値を設定する必要があります。

ストレージアカウントの場合は、ストレージアカウントの接続文字列に値を設定します。
エミュレーターの場合は、値を UseDevelopmentStorage=true に設定します。

エミュレーターを使用する場合は、デプロイの前に、この設定を実際のストレージアカウント接続文字列に変更します。詳細については、ローカルストレージエミュレーターに関するページを参照してください。

ストレージアカウントの接続文字列を設定するには、次の手順を実行します。

Azure portal にサインインし、ストレージアカウントに移動します。
セキュリティ + ネットワーク>アクセスキーを選択します。 key1 で、接続文字列の値をコピーします。
Visual Studio プロジェクトで、 local.settings.json ファイルを開きます。 AzureWebJobsStorage キーの値をコピーした接続文字列に設定します。
前の手順を繰り返し、関数に必要なその他のすべての接続について、Values 配列に一意のキーを追加します。

プロジェクトに関数を追加する

C# クラスライブラリ関数では、関数が使用するバインドは、コード内の属性を適用することによって定義されます。提供されているテンプレートから関数トリガーを作成する場合は、トリガー属性が適用されます。

[ソリューションエクスプローラー] で、プロジェクトノードを右クリックして [追加]>[新しい Azure 関数] を選びます。
[ 新しい項目の追加 ] ダイアログで、[ Azure 関数] を選択し、[ 追加] を選択します。
トリガーを選択し、必要なバインドプロパティを設定します。ストレージサービストリガーを選択し、接続を構成する場合は、トリガー接続を構成するためのチェックボックスをオンにします。次の例は、Queue Storage トリガー関数を作成するための設定を示しています。
[] を選択し、[] を追加します。前の手順でストレージ接続を構成するためのチェックボックスをオンにすると、[ 依存関係への接続 ] ページが表示されます。 Azurite ストレージエミュレーターまたは Azure Storage を選択し、[ 次へ] を選択します。
- Azurite ストレージエミュレーターを選択すると、 ストレージ Azurite エミュレーターへの接続 ページが表示されます。次の手順を実行します。
  1. [次へ] を選択します。
  2. [ 変更の概要 ] ページで、[ 完了] を選択します。 Visual Studio によって依存関係が構成され、トリガークラスが作成されます。
- Azure Storage を選択すると、[Azure Storage への接続] ページが表示されます。次の手順を実行します。
  1. ストレージアカウントを選択し、[ 次へ] を選択します。 Visual Studio は、Azure アカウントへの接続とエンドポイントの取得を試みます。
  2. [次へ] を選択します。
  3. [ 変更の概要 ] ページで、[ 完了] を選択します。 Visual Studio によって依存関係が構成され、トリガークラスが作成されます。
このトリガーの例では、QueueStorage という名前のキーを使うストレージ接続に対するアプリケーション設定を使います。このキーは、 local.settings.json ファイルに格納され、Azurite エミュレーターまたはストレージアカウントを参照します。

新しく追加されたクラスを確認します。たとえば、次の C# クラスは、基本的な Queue Storage トリガー関数を表します。

Run() メソッドは、Functionで属性付けされます。この属性は、メソッドが関数のエントリポイントであることを示します。

using System;
using Azure.Storage.Queues.Models;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function;

public class QueueTriggerCSharp
{
    private readonly ILogger<QueueTriggerCSharp> _logger;

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

    [Function(nameof(QueueTriggerCSharp))]
    public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")] QueueMessage message)
    {
        _logger.LogInformation("C# Queue trigger function processed: {messageText}", message.MessageText);
    }
}

静的 Run() メソッドは、 FunctionNameで属性付けされます。この属性は、メソッドが関数のエントリポイントであることを示します。

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class QueueTriggerCSharp
    {
        [FunctionName("QueueTriggerCSharp")]
        public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")]string myQueueItem, ILogger log)
        {
            log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        }
    }
}

バインド固有の属性は、エントリポイントメソッドに指定された各バインドパラメーターに適用されます。属性ではパラメーターとしてバインド情報を取ります。

前のコードでは、最初のパラメーターには、Queue Storage トリガー関数を示す QueueTrigger 属性が適用されています。キュー名および接続文字列の設定名は、パラメーターとして QueueTrigger 属性に渡されます。クラスで次の手順を実行します。

キュー名パラメーターは、前の手順でトリガーを作成するために使用したキューの名前 ( myqueue-items など) と一致する必要があります。
接続文字列の設定名は、前の手順でトリガーを作成するために使用した名前 ( QueueStorageなど) と一致する必要があります。

詳細については、 Azure Functions の Azure Queue Storage トリガーに関するページを参照してください。

前の手順を使用して、関数アプリプロジェクトに関数を追加します。プロジェクト内の各関数で異なるトリガーを使用できますが、1 つの関数には 1 つのトリガーのみを使用する必要があります。詳細については、「 Azure Functions のトリガーとバインド」を参照してください。

バインドの追加

トリガーと同じように、入力バインドと出力バインドも、バインド属性として関数に追加されます。関数にバインドを追加するには、次の手順を実行します。

プロジェクトをローカル開発用に構成していることを確認します。
特定のバインドごとに適切な NuGet 拡張機能パッケージを追加します。バインド固有の NuGet パッケージの要件については、バインディングのリファレンス記事を参照してください。たとえば、Azure Event Hubs トリガーのパッケージ要件については、 Azure Functions の Azure Event Hubs トリガーとバインドに関するページを参照してください。
パッケージマネージャーコンソールで次のコマンドを使用して、特定のパッケージをインストールします。
```
Install-Package Microsoft.Azure.Functions.Worker.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
```
```
Install-Package Microsoft.Azure.WebJobs.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
```
このコードでは、 <BINDING_TYPE> をバインド拡張機能の特定の名前に置き換え、 <TARGET_VERSION> を 4.0.0などの特定のバージョンのパッケージに置き換えます。有効なバージョンは、NuGet.org の個々のパッケージページに記載されています。
バインドが必要なアプリ設定がある場合は、Valuesのコレクションに追加します。

この関数では、ローカルで実行するときにこれらの値を使用します。関数が Azure の関数アプリで実行される場合は、関数アプリの設定が使用されます。 Visual Studio を使うと、簡単にローカル設定を Azure に発行できます。

適切なバインド属性をメソッドシグネチャに追加します。次のコードでは、キューメッセージによって Run 関数がトリガーされます。次に、出力バインドによって、同じテキストを持つ新しいキューメッセージが別のキューに作成されます。

 public class QueueTrigger
{
    private readonly ILogger _logger;

    public QueueTrigger(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger<QueueTrigger>();
    }

    [Function("CopyQueueMessage")]
    [QueueOutput("myqueue-items-destination", Connection = "QueueStorage")]
    public string Run([QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem)
    {
        _logger.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        return myQueueItem;
    }
}

QueueOutput 属性は、メソッドでのバインドを定義します。複数の出力バインドの場合は、代わりに、返されるオブジェクトの文字列プロパティにこの属性を配置します。詳しくは、「複数の出力バインディング」をご覧ください。

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem, 
        [Queue("myqueue-items-destination", Connection = "QueueStorage")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

Queue パラメーターの out 属性は、出力バインディングを定義します。

Queue Storage への接続は、 QueueStorage 設定から取得されます。詳しくは、特定のバインドの参照記事をご覧ください。

Functions でサポートされるバインドを網羅した一覧については、「サポートされるバインディング」を参照してください。このシナリオのより完全な例については、「 Visual Studio を使用して Azure Storage に関数を接続する」を参照してください。

関数をローカルで実行する

Azure Functions Core Tools を使用して、ローカル開発コンピューターで Functions プロジェクトを実行できます。 F5 キーを押して Functions プロジェクトをデバッグすると、ローカルの Functions ホスト (func.exe) がローカルポート (通常は 7071) でリッスンを開始します。呼び出し可能な関数エンドポイントが出力に書き込まれるので、それらのエンドポイントを関数のテストに使用できます。詳細については、「 Core Tools を使用して Azure Functions をローカルに開発する」を参照してください。 Visual Studio から初めて関数を起動すると、これらのツールをインストールするよう求めるメッセージが表示されます。

重要

Core Tools のバージョン 4.0.6517 以降、インプロセスモデルプロジェクトでは、Microsoft.NET.Sdk.Functions のバージョン 4.5.0 以降を参照する必要があります。以前のバージョンを使用している場合は、 func start コマンドによってエラーが生成されます。

Visual Studio でデバッグモードで関数を開始するには、次の手順を実行します。

F5 キーを押します。メッセージが表示されたら、Visual Studio から Azure Functions Core Tools をダウンロードしてインストールする要求を受け入れます。ツールが HTTP 要求を処理できるように、ファイアウォール例外を有効にする必要がある場合もあります。
プロジェクトの実行時に、デプロイされた関数をテストするのと同じ方法でコードをテストします。

Visual Studio をデバッグモードで実行すると、想定どおりにブレークポイントにヒットします。

Visual Studio を使用するより詳細なテストシナリオについては、この記事の後半の「テスト関数」を参照してください。

Azure に発行する

Functions プロジェクトを Azure に発行すると、Visual Studio は zip デプロイを使用してプロジェクトファイルをデプロイします。可能な場合は、[ パッケージファイルから実行 ] を選択して、プロジェクトが配置 (.zip) パッケージで実行されるようにする必要もあります。詳しくは、「Azure でパッケージファイルから関数を実行する」をご覧ください。

Web 配置 (msdeploy) を使用して Functions にデプロイしないでください。

Azure の関数アプリにプロジェクトを発行するには、次の手順に従います。

ソリューションエクスプローラーで、プロジェクトを右クリックし、[発行] を選択します。
[ 発行 ] ページで、次の選択を行います。
- [ターゲット] で [Azure] を選択し、[次へ] を選択します。
- [特定のターゲット] で、[Azure Function App] を選択し、[次へ] を選択します。
- Functions インスタンスで、[新規作成] を選択します。

次の表に示されている値を使用して、新しいインスタンスを作成します。

設定	値	説明
名前	グローバルに一意の名前	名前は、新しい関数アプリを一意に識別する必要があります。推奨される名前をそのまま使用するか、新しい名前を入力します。有効な文字は、 `a-z`、 `0-9`、および `-`です。
サブスクリプション名	サブスクリプションの名前	関数アプリは、Azure サブスクリプションに作成されます。既定のサブスクリプションをそのまま使用するか、一覧から別のサブスクリプションを選択します。
リソースグループ	リソースグループの名前	関数アプリはリソースグループに作成されます。 [新規作成] を選択して、新しいリソースグループを作成します。一覧から既存のリソースグループを選択することもできます。
プランの種類	Flex Consumption	Flex Consumption プランで実行されている関数アプリにプロジェクトを発行する場合、関数アプリの実行に対してのみ支払う場合があります。その他のホスティングプランでは、コストが高くなる可能性があります。重要: Flex 従量課金プランを作成するときは、まず App Service プランを選択してから、Flex Consumption を再選択してダイアログの問題をクリアする必要があります。
オペレーティングシステム	リナックス	Flex 従量課金プランには現在、Linux が必要です。
場所	アプリサービスの場所	Flex 従量課金プランでサポートされている Azure リージョン内の場所を選択します。サポートされていないリージョンが選択されている場合、[ 作成 ] ボタンは淡色表示されます。
インスタンスメモリサイズ	2048	アプリが実行される仮想マシンインスタンスのメモリサイズは、Flex 従量課金プランに固有です。
Azure Storage	汎用ストレージアカウント	Functions ランタイムにはストレージアカウントが必要です。 [新規] を選択して汎用ストレージアカウントを構成します。ストレージアカウントの要件を満たす既存のアカウントを使用することもできます。
Application Insights	Application Insights のインスタンス	関数アプリの Application Insights 統合を有効にする必要があります。新規または既存の Log Analytics ワークスペースで、[新規作成] を選択して新しいインスタンスを作成します。既存のインスタンスを使用することもできます。

$[Function App Create new]$関数アプリの新しい作成$ ダイアログのスクリーンショット。名前、サブスクリプション、リソースグループ、プラン、およびその他の設定のフィールドが入力されます。$

[作成] を選択して、関数アプリとその関連リソースを Azure で作成します。リソース作成の状態はウィンドウの左下に表示されます。
完了を選択します。 [ 発行プロファイルの作成の進行状況 ] ウィンドウが表示されます。プロファイルが作成されたら、[ 閉じる] を選択します。
[発行プロファイル] ページで、[ 発行 ] を選択して、プロジェクトファイルを含むパッケージを Azure の新しい関数アプリにデプロイします。

デプロイが完了すると、Azure の関数アプリのルート URL が発行プロファイルページに表示されます。
発行プロファイルページで、[ ホスティング ] セクションに移動します。省略記号 (...) を選択し、[ Azure portal で開く] を選択します。新しい関数アプリの Azure リソースが Azure portal で開きます。

Function App の設定

Visual Studio では、プロジェクトの発行時にアプリ設定が自動的にアップロードされることはありません。 local.settings.json ファイルに設定を追加する場合は、Azure の関数アプリにも設定を追加する必要があります。

必要な設定を Azure の関数アプリにアップロードする最も簡単な方法は、Visual Studio でそれらを管理することです。発行プロファイルページで、[ ホスティング ] セクションに移動します。省略記号 (...) を選択し、[ Azure App Service 設定の管理] を選択します。

選択すると、関数アプリの [アプリケーション設定 ] ダイアログが開きます。このダイアログを使用して、アプリケーション設定を追加したり、既存の設定を変更したりできます。

さまざまな設定のローカル値とリモート値、および値を追加および編集するためのコントロールを示す [アプリケーション設定] ダイアログのスクリーンショット。

各設定の ローカル 値は local.settings.json ファイル内の値であり、 Remote 値は Azure の関数アプリの値です。

アプリ設定を作成するには、[ 設定の追加] を選択します。
[ローカル] フィールドから [リモート] フィールドに設定値をコピーするには、[ローカルから値を挿入] を選択します。

[OK] を選択すると、保留中の変更がローカル設定ファイルと関数アプリに書き込まれます。

注

既定では、 local.settings.json ファイルはソース管理にチェックインされません。その結果、ソース管理からローカルの Functions プロジェクトを複製した場合、プロジェクトには local.settings.json ファイルがありません。 アプリケーション設定ダイアログが想定どおりに動作するように、プロジェクトルートに local.settings.json ファイルを手動で作成する必要があります。

以下のいずれかの方法を使用して、アプリケーション設定を管理することもできます。

Azure Portal を使用します。
Azure Functions Core Tools の --publish-local-settings 発行オプションを使用します。
Azure CLI を使用します。

リモートデバッグ

関数アプリをリモートでデバッグするには、プロジェクトのデバッグ構成を発行する必要があります。また、Azure の関数アプリでリモートデバッグを有効にする必要もあります。

このセクションでは、関数アプリへのデバッグ構成が公開されていることを前提としています。

リモートデバッグに関する考慮事項

運用環境のサービスでは、リモートデバッグはお勧めしません。
リモートデバッグを使用するには、Premium または App Service プランで関数アプリをホストする必要があります。
リモートデバッグは現在、Windows で C# アプリを実行する場合にのみサポートされています。
Visual Studio で [マイコードのみ] 機能を有効にしている場合は、オフにします。手順については、「マイコードのみを有効または無効にする」を参照してください。
リモートデバッグを使用する場合は、ブレークポイントで長い停止を避けます。プロセスが数分間以上停止されると、Azure は応答しないプロセスとして処理し、シャットダウンします。
デバッグ中に、サーバーは Visual Studio にデータを送信します。これは帯域幅の料金に影響を与える可能性があります。帯域幅レートの詳細については、「料金計算ツール」を参照してください。
リモートデバッグは、48 時間後に関数アプリで自動的にオフになります。その後、リモートデバッグをオンに戻す必要があります。

デバッガーをアタッチする

分離されたワーカープロセスアプリをデバッグするときは、現在、リモートデバッガーを別の .NET プロセスにアタッチする必要があります。その他のいくつかの構成手順も必要です。

Functions ホストとは別のプロセスで実行されている関数アプリにリモートデバッガーをアタッチするには、次の手順を実行します。

発行プロファイルページで、[ ホスティング ] セクションに移動します。省略記号 (...) を選択し、デバッガーをアタッチを選択します。

Visual Studio は関数アプリに接続し、まだ有効にしていない場合はリモートデバッグを有効にします。

注

リモートデバッガーはホストプロセスに接続できないため、エラーメッセージが表示されることがあります。いずれの場合も、ローカルデバッガーはブレークポイントにアクセスしたり、変数を検査したり、コードをステップ実行したりする方法を提供できません。
Visual Studio の [デバッグ ] メニューで、[ プロセスにアタッチ] を選択します。
[ プロセスにアタッチ ] ダイアログで、次の手順を実行します。
1. [ 接続の種類] の横にある Microsoft Azure App Services を選択します。
2. [ 接続ターゲット] の横にある [検索] を選択 します。
[Azure プロセスへのアタッチ] ダイアログで、関数アプリを検索して選択し、[OK] を選択します。
メッセージが表示されたら、ローカルファイアウォール経由で Visual Studio へのアクセスを許可します。
[ プロセスにアタッチ ] ダイアログボックスに戻り、[ すべてのユーザーのプロセスを表示] を選択します。 [dotnet.exe] を選択し、[アタッチ] を選択します。

操作が完了すると、分離されたワーカープロセスで実行されている C# クラスライブラリコードにアタッチされます。この時点で、関数アプリを通常どおりにデバッグできます。

Functions ホストでインプロセスで実行されている関数アプリにリモートデバッガーをアタッチするには、次の手順を実行します。

発行プロファイルページで、[ ホスティング ] セクションに移動します。省略記号 (...) を選択し、デバッガーをアタッチを選択します。

Visual Studio は関数アプリに接続し、まだ有効にしていない場合はリモートデバッグを有効にします。また、アプリのホストプロセスにデバッガーを見つけてアタッチします。この時点で、関数アプリを通常どおりにデバッグできます。

デバッグが完了したら、リモートデバッグをオフにする必要があります。

リモートデバッグをオフにする

コードのリモートデバッグが完了したら、 Azure portal でリモートデバッグをオフにする必要があります。リモートデバッグは、忘れた場合に備えて、48 時間後に自動的にオフになります。

発行プロファイルページで、[ ホスティング ] セクションに移動します。省略記号 (...) を選択し、[ Azure portal で開く] を選択します。 Azure portal が開き、プロジェクトのデプロイ対象の関数アプリが表示されます。
関数アプリで、[ 設定]>[構成] を選択し、[ 全般設定 ] タブに移動します。 [リモートデバッグ] の横にある [オフ] を選択します。 [ 保存] を選択し、[ 続行] を選択します。

関数アプリの再起動後、リモートプロセスにリモート接続できなくなります。 Azure portal でこの同じタブを使用して、Visual Studio の外部でリモートデバッグを有効にすることができます。

モニター機能

関数を監視する推奨される方法は、関数アプリと Application Insights を統合することです。この統合は、Visual Studio の発行中に関数アプリを作成するときに有効にする必要があります。

何らかの理由で発行中に統合が設定されていない場合でも、Azure で関数アプリの Application Insights 統合を有効にする必要があります。

監視に Application Insights を使用する方法の詳細については、「 Azure Functions での実行の監視」を参照してください。

テスト関数

このセクションでは、.NET 用のオープンソース単体テストツールである xUnit を使用してテストできる C# インプロセスモデルプロジェクトを作成する方法について説明します。

手順 1: 設定

次の手順に従って、テストをサポートするために必要なアプリプロジェクトと関数を含む環境を構成します。

Visual Studio で、 Functions という名前の Azure Functions プロジェクトを作成します。
テンプレートから HTTP 関数を作成します。
1. ソリューションエクスプローラーで、Functions プロジェクトを右クリックし、[追加>新しい Azure 関数] を選択します。
2. [ 新しい項目の追加 ] ダイアログで、[ Azure 関数] を選択し、[ 追加] を選択します。
3. [Http トリガー] を選択し、[追加] を選択します。
4. 新しいクラス MyHttpTrigger の名前を変更します。
テンプレートからタイマー関数を作成します。
1. ソリューションエクスプローラーで、Functions プロジェクトを右クリックし、[追加>新しい Azure 関数] を選択します。
2. [ 新しい項目の追加 ] ダイアログで、[ Azure 関数] を選択し、[ 追加] を選択します。
3. [タイマートリガー] を選択し、[追加] を選択します。
4. 新しいクラス MyTimerTrigger の名前を変更します。
ソリューションで xUnit テストアプリを作成します。
1. ソリューションエクスプローラーで、Functions プロジェクトを含むソリューションを右クリックし、[ 追加>新しいプロジェクト] を選択します。
2. xUnit テストプロジェクト テンプレートを選択し、[次へ] を選択します。
3. プロジェクトに Functions.Tests という名前を付けます。
Functions.Tests プロジェクトから既定のテストファイルを削除します。
NuGet を使用して、テストアプリから Microsoft.AspNetCore.Mvc への参照を追加します。パッケージマネージャーコンソールを使用することも、次の手順を実行することもできます。
1. ソリューションエクスプローラーでFunctions.Tests プロジェクトを右クリックし、[NuGet パッケージの管理] を選択します。
2. Microsoft.AspNetCore.Mvc を検索してインストールします。
Functions.Tests アプリで、Functions アプリへの参照を追加します。
1. ソリューションエクスプローラーでFunctions.Tests プロジェクトを右クリックし、>を選択します。
2. Functions プロジェクトを選択し、[OK] を選択します。

手順 2: テストクラスを作成する

このセクションでは、自動テストの実行に使用するクラスを作成します。

各関数は、メッセージログを処理するために ILogger の実装を受け取ります。一部のテストでは、メッセージがログに記録されないか、ログ記録の実装方法は関係ありません。他のテストでは、ログに記録されたメッセージを評価して、テストに合格するかどうかを判断する必要があります。

という名前の NullScope プロジェクトにクラスを作成し、次のコードを追加します。このクラスはモックスコープを提供します。後の手順では、このスコープを使用する ILogger の実装を作成します。
```
using System;

namespace Functions.Tests
{
    public class NullScope : IDisposable
    {
        public static NullScope Instance { get; } = new NullScope();

        private NullScope() { }

        public void Dispose() { }
    }
}
```
という名前の ListLogger プロジェクトにクラスを作成し、次のコードを追加します。このクラスは、テスト中に評価するメッセージの内部リストを保持します。必要な ILogger インターフェイスを実装するために、クラスは NullScope クラスのモックスコープを使用します。テストケースは、モックスコープを ListLogger クラスに渡します。
```
using Microsoft.Extensions.Logging;
using System;
using System.Collections.Generic;
using System.Text;

namespace Functions.Tests
{
    public class ListLogger : ILogger
    {
        public IList<string> Logs;

        public IDisposable BeginScope<TState>(TState state) => NullScope.Instance;

        public bool IsEnabled(LogLevel logLevel) => false;

        public ListLogger()
        {
            this.Logs = new List<string>();
        }

        public void Log<TState>(LogLevel logLevel,
                                EventId eventId,
                                TState state,
                                Exception exception,
                                Func<TState, Exception, string> formatter)
        {
            string message = formatter(state, exception);
            this.Logs.Add(message);
        }
    }
}
```
ListLogger クラスは、ILogger インターフェイスによってコントラクト化された次のメンバーを実装します。
- BeginScope: スコープによって、ログ記録にコンテキストが追加されます。この場合、テストは、テストが機能できるように、 NullScope クラスの静的インスタンスを指します。
- IsEnabled: 既定値の false が指定されています。
- Log: このメソッドは、指定された formatter 関数を使用してメッセージの書式設定を行います。次に、結果のテキストを Logs コレクションに追加します。
Logs コレクションは List<string> のインスタンスであり、コンストラクターで初期化されます。
LoggerTypes.csという名前のコードファイルを Functions.Tests プロジェクトに作成し、次のコードを追加します。
```
namespace Functions.Tests
{
    public enum LoggerTypes
    {
        Null,
        List
    }
}
```
この列挙型は、テストで使用されるロガーの種類を指定します。

という名前の TestFactory プロジェクトにクラスを作成し、次のコードを追加します。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Internal;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Abstractions;
using Microsoft.Extensions.Primitives;
using System.Collections.Generic;

namespace Functions.Tests
{
    public class TestFactory
    {
        public static IEnumerable<object[]> Data()
        {
            return new List<object[]>
            {
                new object[] { "name", "Bernardo" },
                new object[] { "name", "Ananya" },
                new object[] { "name", "Vlad" }

            };
        }

        private static Dictionary<string, StringValues> CreateDictionary(string key, string value)
        {
            var qs = new Dictionary<string, StringValues>
            {
                { key, value }
            };
            return qs;
        }

        public static HttpRequest CreateHttpRequest(string queryStringKey, string queryStringValue)
        {
            var context = new DefaultHttpContext();
            var request = context.Request;
            request.Query = new QueryCollection(CreateDictionary(queryStringKey, queryStringValue));
            return request;
        }

        public static ILogger CreateLogger(LoggerTypes type = LoggerTypes.Null)
        {
            ILogger logger;

            if (type == LoggerTypes.List)
            {
                logger = new ListLogger();
            }
            else
            {
                logger = NullLoggerFactory.Instance.CreateLogger("Null Logger");
            }

            return logger;
        }
    }
}

TestFactory クラスは、次のメンバーを実装します。

Data: このプロパティは、サンプルデータの IEnumerable コレクションを返します。キーと値のペアは、クエリ文字列に渡される値を表します。
CreateDictionary: このメソッドは、キーと値のペアを引数として受け入れます。クエリ文字列値を表すDictionaryのインスタンスを作成するために使用されるQueryCollectionの新しいインスタンスが返されます。
CreateHttpRequest: このメソッドは、指定されたクエリ文字列パラメーターを使用して初期化される HTTP 要求を作成します。
CreateLogger: このメソッドは、テストに使用される ILogger の実装を返します。 ILogger実装は、指定したロガーの種類によって異なります。リストの種類が指定されている場合、 ListLogger インスタンスは、テストで評価に使用できるログに記録されたメッセージを追跡します。

という名前の FunctionsTests プロジェクトにクラスを作成し、次のコードを追加します。

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using Xunit;

namespace Functions.Tests
{
    public class FunctionsTests
    {
        private readonly ILogger logger = TestFactory.CreateLogger();

        [Fact]
        public async void Http_trigger_should_return_known_string()
        {
            var request = TestFactory.CreateHttpRequest("name", "Bernardo");
            var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger);
            Assert.Equal("Hello, Bernardo. This HTTP triggered function executed successfully.", response.Value);
        }

        [Theory]
        [MemberData(nameof(TestFactory.Data), MemberType = typeof(TestFactory))]
        public async void Http_trigger_should_return_known_string_from_member_data(string queryStringKey, string queryStringValue)
        {
            var request = TestFactory.CreateHttpRequest(queryStringKey, queryStringValue);
            var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger);
            Assert.Equal($"Hello, {queryStringValue}. This HTTP triggered function executed successfully.", response.Value);
        }

        [Fact]
        public void Timer_should_log_message()
        {
            var logger = (ListLogger)TestFactory.CreateLogger(LoggerTypes.List);
            new MyTimerTrigger().Run(null, logger);
            var msg = logger.Logs[0];
            Assert.Contains("C# Timer trigger function executed at", msg);
        }
    }
}

このクラスは、次のメンバーを実装します。

Http_trigger_should_return_known_string: このテストでは、クエリ文字列値 name=Bernardo を使用して、HTTP 関数への要求を作成します。このテストでは、予想される応答が返されることを確認します。
Http_trigger_should_return_string_from_member_data: このテストでは、xUnit 属性を使用して、HTTP 関数にサンプルデータを提供します。
Timer_should_log_message: このテストでは、 ListLogger のインスタンスを作成し、タイマー関数に渡します。関数の実行後、ログがチェックされ、予期されるメッセージが存在することを確認します。

テストのアプリケーション設定にアクセスするには、モック環境変数値を含む実装を関数にIConfigurationします。

手順 3: テストを実行する

Visual Studio でテストを実行するには、[表示]>[テストエクスプローラー] を選択します。 テストエクスプローラーで、[実行] >[すべてのテストを表示で実行] を選択します。

Visual Studio のスクリーンショット。テストエクスプローラーには、5 つのテストに合格したと表示されます。ソリューションエクスプローラーでは、Functions および Functions.Test プロジェクトが表示されます。

手順 4: テストをデバッグする

テストをデバッグするには、テストにブレークポイントを設定します。 テストエクスプローラーで、[実行>Debug Last Run] を選択します。

Core Tools を使用して Azure Functions をローカルで開発する

C# インプロセスモデルガイド

C# 分離ワーカーモデルガイド

フィードバック

このページはお役に立ちましたか?