分離ワーカーモデルで C# Azure Functions を実行するためのガイド

[アーティクル]
09/05/2024

この記事は、Azure Functions を .NET で、分離ワーカーモデルを使用して扱うための入門となるものです。このモデルでは、他のランタイムコンポーネントとは独立して .NET のバージョンをプロジェクトのターゲットとすることができます。サポートされている特定の .NET バージョンの詳細については、「サポートされているバージョン」を参照してください。

次のリンクを使用すると .NET 分離ワーカーモデル関数の構築を今すぐ開始できます。

作業の開始	概念	サンプル
Visual Studio Code の使用コマンドラインツールの使用 Visual Studio の使用	ホスティングオプション Monitoring	リファレンスのサンプル

分離ワーカーモデルプロジェクトを Azure にデプロイする方法について学ぶには、「Azure Functions へのデプロイ」を参照してください。

分離ワーカーモデルの利点

.NET クラスライブラリ関数の実行モードは 2 つあり、1 つは Functions ホストランタイムと同じプロセス内 ("インプロセス") で実行、もう 1 つは分離ワーカープロセス内で実行するというものです。 .NET 関数を分離ワーカープロセスで実行すると、次のような利点を利用できます。

競合が少ない: 関数は独立したプロセスの中で実行されるため、アプリで使用されるアセンブリが、ホストプロセスで使用される同じアセンブリの別のバージョンと競合することはありません。
プロセスの完全制御: 開発者がアプリの起動を制御できます。つまり、使用される構成と起動されるミドルウェアを開発者が制御できます。
標準の依存関係の挿入: 開発者がプロセスを完全制御できるので、現在の .NET 動作を使用して依存関係の挿入や関数アプリへのミドルウェアの組み込みを行うことができます。
.NET のバージョンの柔軟性: ホストプロセスの外部で実行されるため、Functions ランタイムでネイティブにサポートされていないバージョンの .NET (これには .NET Framework も含まれます) 上で関数を実行できます。

既存の C# 関数アプリがインプロセスで実行されている場合に、これらの利点を活用するには、そのアプリを移行する必要があります。詳細については、「.NET アプリをインプロセスモデルから分離ワーカーモデルに移行する」を参照してください。

2 つのモード間の総合的な比較については、インプロセスと分離ワーカープロセスの .NET Azure Functions の違いに関するページを参照してください。

サポートされているバージョン

Functions ランタイムの各バージョンでは、.NET の特定のバージョンがサポートされています。 Functions のバージョンの詳細については、「Azure Functions ランタイムバージョンの概要」を参照してください。バージョンのサポートは、関数がインプロセスで実行されるか、分離ワーカープロセスで実行されるかによっても異なります。

Note

関数アプリで使用される Functions ランタイムバージョンを変更する方法については、「現在のランタイムバージョンの表示と更新」を参照してください。

次の表は、特定のバージョンの Functions と共に使用できる最上位レベルの .NET と .NET Framework を示しています。

Functions ランタイムのバージョン	分離ワーカーモデル	インプロセスモデル⁵
Functions 4.x¹	.NET 9.0 (プレビュー) .NET 8.0 .NET 6.0² .NET Framework 4.8³	.NET 8.0 .NET 6.0²
Functions 4.x¹	該当なし	.NET Framework 4.8

¹ .NET 7 は、以前は分離ワーカーモデルでサポートされていましたが、2024 年 5 月 14 日に公式サポートが終了しました。

² .NET 6 は 2024 年 11 月 12 日に公式サポート終了となります。

³ ビルドプロセスには .NET SDK も必要です。

⁴ Azure Functions ランタイムのバージョン 1.x のサポートは 2026 年 9 月 14 日に終了します。詳細については、こちらのサポートに関するお知らせを参照してください。引き続き完全なサポートを受けるには、アプリをバージョン 4.x に移行する必要があります。

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

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

プロジェクト構造

分離ワーカーモデルを使用する Azure Functions 用 .NET プロジェクトは、基本的には、サポートされる .NET ランタイムをターゲットとする .NET コンソールアプリプロジェクトです。以下は、.NET 分離プロジェクトで必要となる基本的なファイルです。

プロジェクトと依存関係を定義する C# プロジェクトファイル (.csproj)
アプリのエントリポイントである Program.cs ファイル。
関数を定義するすべてのコードファイル。
プロジェクト内の関数に共通する構成を定義する host.json ファイル。
プロジェクトをマシン上でローカルに実行するときに使用される環境変数を定義する local.settings.json ファイル。

詳細な例については、.NET 8 サンプルプロジェクトと .NET Framework 4.8 サンプルプロジェクトを参照してください。

パッケージ参照

分離ワーカーモデルを使用する Azure Functions 用 .NET プロジェクトでは、コア機能とバインド拡張機能の両方に対して、一意のパッケージセットが使用されます。

コアパッケージ

.NET 関数を分離ワーカープロセスで実行するには、次のパッケージが必要です。

バージョン 2.x (プレビュー)

コアパッケージの 2.x バージョンでは、サポートされているフレームワーク資産が変更され、この新しいバージョン以降の新しい .NET API がサポートされています。 .NET 9 (プレビュー) 以降を使用する場合、アプリは両方のパッケージのバージョン 2.0.0-preview1 以降を参照する必要があります。

初期のプレビューバージョンは、バージョン 1.x に対して記述されたコードと互換性があります。ただし、プレビュー期間中は、記述するコードが、新しいバージョンによる動作変更の影響を受ける可能性があります。

2.x バージョンに更新する場合は、次の変更に注意してください。

バージョン 2.0.0-preview2 以降では、Microsoft.Azure.Functions.Worker.Sdk が SDK コンテナービルドの既定の構成に追加されています。

拡張機能パッケージ

.NET 分離ワーカープロセス関数はさまざまなバインドの種類を使用するため、バインド拡張機能パッケージの一意のセットが必要になります。

これらの拡張機能パッケージは、Microsoft.Azure.Functions.Worker.Extensions にあります。

スタートアップと構成

.NET 分離関数を使用する場合、通常は Program.cs にある関数アプリのスタートアップにアクセスできます。各自のホストインスタンスの作成と開始は、お客様が担当します。そのため、自分のアプリの構成パイプラインに直接アクセスすることもできます。 .NET Functions 分離ワーカープロセスでは、構成の追加、依存関係の挿入、および独自のミドルウェアの実行がはるかに簡単になります。

次のコードは HostBuilder パイプラインの例を示します。

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(s =>
    {
        s.AddApplicationInsightsTelemetryWorkerService();
        s.ConfigureFunctionsApplicationInsights();
        s.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
        s.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://video2.skills-academy.com/en-us/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule toRemove = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");

            if (toRemove is not null)
            {
                options.Rules.Remove(toRemove);
            }
        });
    })
    .Build();

このコードでは using Microsoft.Extensions.DependencyInjection; が必要です。

HostBuilder 上の Build() を呼び出す前に、以下の操作を行う必要があります。

ASP.NET Core 統合を使用している場合は ConfigureFunctionsWebApplication() を呼び出し、それ以外の場合は ConfigureFunctionsWorkerDefaults() を呼び出します。これらのオプションの詳細については、「HTTP トリガー」を参照してください。
アプリケーションのプログラミングに F# を使用する場合は、一部のトリガーおよびバインド拡張機能に追加の構成が必要になります。 BLOB 拡張機能、テーブル拡張機能、Cosmos DB 拡張機能を F# アプリで使用する予定がある場合は、これらの拡張機能のセットアップのドキュメントを参照してください。
プロジェクトで必要なサービスまたはアプリ構成を構成します。詳細については「構成」を参照してください。
Application Insights を使用する予定の場合は、ConfigureServices() デリゲートで AddApplicationInsightsTelemetryWorkerService() と ConfigureFunctionsApplicationInsights() を呼び出す必要があります。詳細については、「Application Insights」を参照してください。

プロジェクトのターゲットが .NET Framework 4.8 の場合は、HostBuilder を作成する前に FunctionsDebugger.Enable(); を追加する必要もあります。これは、Main() メソッドの最初の行である必要があります。詳細については、「.NET Framework をターゲットにするときのデバッグ」を参照してください。

HostBuilder は、完全に初期化された IHost インスタンスを構築して返すために使用されます。このインスタンスを非同期で実行して関数アプリを起動します。

await host.RunAsync();

構成

分離ワーカープロセス内で関数アプリを実行するために必要な設定の追加には ConfigureFunctionsWorkerDefaults メソッドが使用されます。これには、次の機能が含まれます。

コンバーターの既定のセット。
プロパティ名の大文字と小文字の区別を無視するための既定の JsonSerializerOptions への設定。
Azure Functions ログとの統合。
出力バインディングミドルウェアと機能。
関数の実行ミドルウェア。
既定の gRPC サポート。

.ConfigureFunctionsWorkerDefaults()

ホストビルダーパイプラインにアクセスできるということは、初期化中にあらゆるアプリ固有の構成を設定できることも意味します。 ConfigureAppConfiguration メソッドを HostBuilder で 1 回以上呼び出して、関数アプリに必要な構成を追加できます。アプリ構成について詳しくは、「ASP.NET Core の構成」を参照してください。

これらの構成は、別のプロセスで実行している関数アプリに適用されます。 Functions ホストまたはトリガーおよびバインド構成に変更を加えるには、この場合も host.json ファイルを使用する必要があります。

Note

カスタム構成ソースは、トリガーとバインドの構成には使用できません。トリガーとバインドの構成は、アプリケーションコードだけでなく、Functions プラットフォームからも利用できる必要があります。この構成は、アプリケーション設定、Key Vault 参照、または App Configuration 参照機能を通して指定できます。

依存関係の挿入

依存関係の挿入は .NET インプロセス関数 (サービスを登録するためにスタートアップクラスの作成が必要です) に比べると単純化されています。

.NET 分離プロセスアプリの場合は .NET 標準の方法を使用します。つまり ConfigureServices をホストビルダーに対して呼び出し、IServiceCollection の拡張メソッドを使用して特定のサービスを挿入します。

次の例では、シングルトンサービスの依存関係を挿入します。

.ConfigureServices(services =>
{
    services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();
})

このコードでは using Microsoft.Extensions.DependencyInjection; が必要です。詳細については、「ASP.NET Core での依存関係の挿入」を参照してください。

Azure クライアントを登録する

依存関係の挿入は、他の Azure サービスと対話するために使用できます。 Microsoft.Extensions.Azure パッケージを使って、Azure SDK for .NET からクライアントを挿入できます。パッケージをインストールした後、Program.cs のサービスコレクションで AddAzureClients() を呼び出してクライアントを登録します。次の例では、Azure BLOB の名前付きクライアントを構成します。

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

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((hostContext, services) =>
    {
        services.AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(hostContext.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });
    })
    .Build();

host.Run();

次の例は、この登録と SDK タイプを使って、挿入されたクライアントを使って、あるコンテナーから別のコンテナーに BLOB コンテンツをストリームとしてコピーする方法を示しています。

using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public class BlobCopier
    {
        private readonly ILogger<BlobCopier> _logger;
        private readonly BlobContainerClient _copyContainerClient;

        public BlobCopier(ILogger<BlobCopier> logger, IAzureClientFactory<BlobServiceClient> blobClientFactory)
        {
            _logger = logger;
            _copyContainerClient = blobClientFactory.CreateClient("copierOutputBlob").GetBlobContainerClient("samples-workitems-copy");
            _copyContainerClient.CreateIfNotExists();
        }

        [Function("BlobCopier")]
        public async Task Run([BlobTrigger("samples-workitems/{name}", Connection = "MyStorageConnection")] Stream myBlob, string name)
        {
            await _copyContainerClient.UploadBlobAsync(name, myBlob);
            _logger.LogInformation($"Blob {name} copied!");
        }

    }
}

この例の ILogger<T> も依存関係の挿入を通じて取得されたものであり、したがって自動的に登録されます。ログ記録の構成オプションの詳細については、「ログ記録」を参照してください。

ヒント

この例では、Program.cs と関数の両方でクライアント名のリテラル文字列を使いました。代わりに、関数クラスで定義された共有定数文字列の使用を検討してください。たとえば、public const string CopyStorageClientName = nameof(_copyContainerClient); を追加し、両方の場所で BlobCopier.CopyStorageClientName を参照できます。同様に、Program.cs ではなく関数を使って構成セクション名を定義することもできます。

ミドルウェア

分離ワーカーモデルはでは、ASP.NET にあるものと同様のモデルを使用して、ミドルウェア登録もサポートしています。このモデルを使用すると、呼び出しパイプラインにロジックを挿入したり、関数の実行前と実行後にロジックを挿入したりすることができます。

ConfigureFunctionsWorkerDefaults 拡張メソッドには、次の例に示すように、独自のミドルウェアを登録できるオーバーロードがあります。

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(workerApplication =>
    {
        // Register our custom middlewares with the worker

        workerApplication.UseMiddleware<ExceptionHandlingMiddleware>();

        workerApplication.UseMiddleware<MyCustomMiddleware>();

        workerApplication.UseWhen<StampHttpHeaderMiddleware>((context) =>
        {
            // We want to use this middleware only for http trigger invocations.
            return context.FunctionDefinition.InputBindings.Values
                          .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
        });
    })
    .Build();

UseWhen 拡張メソッドを使用して、条件付きで実行されるミドルウェアを登録できます。ブール値を返す述語をこのメソッドに渡す必要があります。述語の戻り値が true のとき、ミドルウェアは呼び出し処理パイプラインに参加します。

FunctionContext に対する次の拡張メソッドにより、分離モデルでのミドルウェアの処理が簡単になります。

メソッド	説明
`GetHttpRequestDataAsync`	HTTP トリガーによって呼び出されたときに `HttpRequestData` インスタンスを取得します。このメソッドは、要求ヘッダーや Cookie などのメッセージデータを読み取るときに便利な `ValueTask<HttpRequestData?>` のインスタンスを返します。
`GetHttpResponseData`	HTTP トリガーによって呼び出されたときに `HttpResponseData` インスタンスを取得します。
`GetInvocationResult`	現在の関数実行の結果を表す `InvocationResult` のインスタンスを取得します。 `Value` プロパティを使用して、必要に応じて値を取得または設定します。
`GetOutputBindings`	現在の関数実行の出力バインドエントリを取得します。このメソッドの結果の各エントリの型は `OutputBindingData` です。 `Value` プロパティを使用して、必要に応じて値を取得または設定できます。
`BindInputAsync`	要求された `BindingMetadata` インスタンスの入力バインド項目をバインドします。たとえば、ミドルウェアで使用する必要のある `BlobInput` 入力バインドを持つ関数があるときに、このメソッドを使用できます。

これは関数の実行中に HttpRequestData インスタンスを読み取り、HttpResponseData インスタンスを更新するミドルウェア実装の例です。

internal sealed class StampHttpHeaderMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        var requestData = await context.GetHttpRequestDataAsync();

        string correlationId;
        if (requestData!.Headers.TryGetValues("x-correlationId", out var values))
        {
            correlationId = values.First();
        }
        else
        {
            correlationId = Guid.NewGuid().ToString();
        }

        await next(context);

        context.GetHttpResponseData()?.Headers.Add("x-correlationId", correlationId);
    }
}

このミドルウェアは、特定の要求ヘッダー (x-correlationId) の存在を確認し、存在するときはヘッダー値を使用して応答ヘッダーをスタンプします。それ以外の場合は、新しい GUID 値を生成し、それを使用して応答ヘッダーをスタンプします。関数アプリでカスタムミドルウェアを使用する詳細な例については、カスタムミドルウェアのリファレンスサンプルを参照してください。

JSON シリアル化のカスタマイズ

分離ワーカーモデルは既定では System.Text.Json を使用します。 Program.cs ファイルの一部としてサービスを構成することで、シリアライザーの動作をカスタマイズできます。このセクションでは、汎用シリアル化について説明します。これは ASP.NET Core 統合での HTTP トリガーの JSON シリアル化には影響せず、それは別に構成する必要があります。

次の例は、ConfigureFunctionsWebApplication を使用してこれを示していますが、ConfigureFunctionsWorkerDefaults でも機能します。

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

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
        {
            jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
            jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
            jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

            // override the default value
            jsonSerializerOptions.PropertyNameCaseInsensitive = false;
        });
    })
    .Build();

host.Run();

代わりに、シリアル化に JSON.NET (Newtonsoft.Json) を使用したい場合があるかもしれません。これを行うには、Microsoft.Azure.Core.NewtonsoftJson パッケージをインストールすることになります。次に、サービス登録で、WorkerOptions 構成で Serializer プロパティを再割り当てします。次の例は、ConfigureFunctionsWebApplication を使用してこれを示していますが、ConfigureFunctionsWorkerDefaults でも機能します。

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

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>
    {
        builder.Services.Configure<WorkerOptions>(workerOptions =>
        {
            var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
            settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            settings.NullValueHandling = NullValueHandling.Ignore;

            workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
        });
    })
    .Build();

host.Run();

関数として認識されるメソッド

関数メソッドは、次の例に示すように、 Function 属性がメソッドに適用され、トリガー属性が入力パラメーターに適用されたパブリッククラスのパブリックメソッドです:

[Function(nameof(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

トリガー属性は、トリガーの種類を指定し、メソッドパラメーターに入力データをバインドします。前の例の関数はキューメッセージによってトリガーされ、そのキューメッセージは myQueueItem パラメーターでメソッドに渡されます。

Function 属性は、関数のエントリポイントとしてメソッドをマークします。名前はプロジェクト内で一意であり、文字で始まり、英数字、_、- のみが含まれ、127 文字以下にする必要があります。プロジェクトテンプレートでは、多くの場合、Run という名前のメソッドが作成されますが、有効な C# メソッド名であればメソッド名として使用できます。このメソッドは、パブリッククラスのパブリックメンバーである必要があります。依存関係の挿入を介してサービスを渡すことができるように、通常はインスタンスメソッド必要があります。

関数のパラメーター

次のようなパラメータを関数メソッドシグネチャの一部として含めることができます。

バインド。パラメータを属性として修飾することによって、バインドであることが指定されます。関数には、トリガーパラメータが厳密に 1 つ含まれている必要があります。
実行コンテキストオブジェクト。現在の呼び出しに関する情報を提供します。
キャンセルトークン。グレースフルシャットダウンに使用されます。

実行コンテキスト

.NET 分離は FunctionContext オブジェクトを関数メソッドに渡します。このオブジェクトを使用すれば、ログに書き込む ILoggerILogger インスタンスを取得できます。これは、GetLogger メソッドを呼び出して ILogger 文字列を指定することで実行します。このコンテキストを使用すると、依存関係の挿入を使用する必要なく ILogger を取得できます。詳細については、「ログ」を参照してください。

キャンセルトークン

関数は CancellationToken パラメーターを受け付けることができます。これにより、オペレーティングシステムは、その関数をいつ終了しようとしているかをコードに通知できます。この通知を使用すれば、関数が予期せず終了してデータが不整合な状態になることを防止できます。

分離ワーカープロセスで実行されているときは、.NET 関数でキャンセルトークンがサポートされます。次の例では、取り消し要求が受信されたときに例外が生成されます。

[Function(nameof(ThrowOnCancellation))]
public async Task ThrowOnCancellation(
    [EventHubTrigger("sample-workitem-1", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(ThrowOnCancellation));

    foreach (var message in messages)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

次の例では、取り消し要求が受信されたときにクリーンアップアクションが実行されます。

[Function(nameof(HandleCancellationCleanup))]
public async Task HandleCancellationCleanup(
    [EventHubTrigger("sample-workitem-2", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(HandleCancellationCleanup));

    foreach (var message in messages)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            _logger.LogInformation("A cancellation token was received, taking precautionary actions.");
            // Take precautions like noting how far along you are with processing the batch
            _logger.LogInformation("Precautionary activities complete.");
            break;
        }

        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

バインド

バインドは、メソッド、パラメーター、および戻り値の型の属性を使用して定義します。バインドでは、文字列、配列、および単純な従来のクラスオブジェクト (POCO) のようなシリアル化可能型としてデータを提供できます。一部のバインド拡張機能では、サービス SDK で定義されているサービス固有の型にバインドすることもできます。

HTTP トリガーについては、HTTP トリガーのセクションを参照してください。

トリガーおよびバインドを分離ワーカープロセス関数と共に使用するリファレンスサンプルの全セットについては、バインド拡張機能のリファレンスサンプルを参照してください。

入力バインディング

関数には、関数にデータを渡すことができる入力バインディングを 0 個以上含めることができます。トリガーと同様、入力バインディングは、入力パラメーターにバインディング属性を適用することによって定義します。関数を実行すると、ランタイムはバインディングで指定されたデータを取得しようとします。要求されるデータは、多くの場合、バインディングパラメーターを使用してトリガーから提供される情報に依存します。

出力バインディング

出力バインドに書き込むには、出力バインド属性を関数メソッドに適用する必要があります。これによって、バインドされたサービスへの書き込みの方法が定義されます。メソッドによって返される値は、出力バインディングに書き込まれます。たとえば、次の例では、出力バインディングを使用して、output-queue という名前のメッセージキューに文字列値を書き込みます。

[Function(nameof(QueueFunction))]
[QueueOutput("output-queue")]
public string[] Run([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
    // Use a string array to return more than one message.
    string[] messages = {
        $"Album name = {myQueueItem.Name}",
        $"Album songs = {myQueueItem.Songs.ToString()}"};

    _logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);

    // Queue Output messages
    return messages;
}

複数の出力バインディング

出力バインディングに書き込まれるデータは、常に関数の戻り値です。複数の出力バインディングに書き込む必要がある場合は、カスタムの戻り値の型を作成する必要があります。この戻り値の型では、出力バインディング属性はクラスの 1 つ以上のプロパティに適用されていなければなりません。次の例は、"ASP.NET Core 統合" を使用して HTTP によってトリガーされる関数です。この関数では、HTTP 応答とキュー出力バインドの両方への書き込みが行われます。

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

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

    [Function("MultipleOutputBindings")]
    public MyOutputType Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
    {
        _logger.LogInformation("C# HTTP trigger function processed a request.");
        var myObject = new MyOutputType
        {
            Result = new OkObjectResult("C# HTTP trigger function processed a request."),
            MessageText = "some output"
        };
        return myObject;
    }

    public class MyOutputType
    {
        [HttpResult]
        public IActionResult Result { get; set; }

        [QueueOutput("myQueue")]
        public string MessageText { get; set; }
    }
}

ASP.NET Core 統合で複数の出力バインドにカスタム戻り値の型を使用する場合は、結果を提供するプロパティに [HttpResult] 属性を追加する必要があります。 HttpResult 属性は、SDK 1.17.3-preview2 以降と、HTTP 拡張機能のバージョン 3.2.0 以降、および ASP.NET Core 拡張機能のバージョン 1.3.0 以降を使う場合に使用できます。

SDK タイプ

一部のサービス固有のバインディングの型では、サービス SDK とフレームワークの型を使用してバインディングデータを提供できます。これらは、シリアル化された文字列や単純な従来の CLR オブジェクト (POCO) では不可能な機能を提供します。新しいタイプを使用するには、コア依存関係の新しいバージョンを使用するようにプロジェクトを更新する必要があります。

依存関係	バージョン要件
Microsoft.Azure.Functions.Worker	1.18.0 以降
Microsoft.Azure.Functions.Worker.Sdk	1.13.0 以上

SDK 型をマシン上でローカルにテストする場合は、Azure Functions Core Tools バージョン 4.0.5000 以降を使用することも必要です。現在のバージョンを確認するには func version コマンドを使用します。

各トリガーとバインド拡張機能にも独自の最小バージョン要件があり、これは拡張機能のリファレンス記事で説明されています。次のサービス固有のバインドでは SDK 型が提供されます。

サービス	トリガー	入力バインド	出力バインド
Azure BLOB	一般提供	一般提供	SDK の型は推奨されません。¹
Azure キュー	一般提供	入力バインドは存在しません	SDK の型は推奨されません。¹
Azure Service Bus	一般提供	入力バインドは存在しません	SDK の型は推奨されません。¹
Azure Event Hubs	一般提供	入力バインドは存在しません	SDK の型は推奨されません。¹
Azure Cosmos DB	SDK 型は使用されません²	一般提供	SDK の型は推奨されません。¹
Azure テーブル	トリガーは存在しません	一般提供	SDK の型は推奨されません。¹
Azure Event Grid	一般提供	入力バインドは存在しません	SDK の型は推奨されません。¹

¹ SDK の型を使用する出力シナリオでは、出力バインドを使用する代わりに、SDK クライアントを直接作成して操作する必要があります。依存関係の挿入の例については、「Azure クライアントの登録」を参照してください。

² Cosmos DB トリガーでは、Azure Cosmos DB の変更フィードが使用され、変更フィードの項目が JSON シリアル化可能な型として公開されます。このシナリオの設計により、SDK 型は存在しません。

Note

トリガーデータに依存するバインド式を使用するとき、トリガー自体の SDK の型は使用できません。

HTTP トリガー

HTTP トリガーを使用すると、HTTP 要求によって関数を呼び出せます。使用できる方法は 2 つあります。

ASP.NET Core 開発者が慣れている概念を使用する ASP.NET Core 統合モデル
組み込みモデル。追加の依存関係は不要であり、カスタム型が HTTP 要求と応答に使用されます。このアプローチは、以前の .NET 分離ワーカーアプリとの後方互換対応を目的として維持されています。

ASP.NET Core の統合

このセクションでは、HttpRequest、HttpResponse、IActionResult などの ASP.NET Core の型を使用して、基になる HTTP 要求オブジェクトと応答オブジェクトを操作する方法について説明します。このモデルは .NET Framework をターゲットとするアプリには使用できません。このようなアプリでは、代わりに組み込みモデルを使用する必要があります。

Note

ASP.NET Core の全機能がこのモデルによって公開されるわけではありません。具体的には、ASP.NET Core ミドルウェアパイプラインとルーティング機能は使用できません。 ASP.NET Core 統合を使用するには、更新されたパッケージを使用する必要があります。

ASP.NET Core 統合を HTTP に対して有効にする手順は次のとおりです。

プロジェクトに Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore パッケージバージョン 1.0.0 以降への参照を追加します。
次に示すパッケージバージョンを使用するようにプロジェクトを更新します。
- Microsoft.Azure.Functions.Worker.Sdk バージョン 1.11.0。 "以降"
- Microsoft.Azure.Functions.Worker バージョン 1.16.0 以降。
Program.cs ファイルで、ConfigureFunctionsWorkerDefaults() の代わりに ConfigureFunctionsWebApplication() を使用するようにホストビルダーの構成を更新します。次の例は、他のカスタマイズを行わない最小限のセットアップを示しています。
```
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .Build();

host.Run();
```
HTTP によってトリガーされる既存の関数がある場合は、ASP.NET Core の型を使用するように更新します。この例では、標準の HttpRequest と IActionResult が単純な "hello, world" 関数に使用されています。
```
[Function("HttpFunction")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
{
    return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
```

ASP.NET Core 統合での JSON のシリアル化

ASP.NET Core には独自のシリアル化レイヤーがあり、一般的なシリアル化構成のカスタマイズによる影響を受けません。 HTTP トリガーに使われるシリアル化の動作をカスタマイズするには、サービス登録の一部として .AddMvc() の呼び出しを含める必要があります。返された IMvcBuilder を使って、ASP.NET Core の JSON シリアル化の設定を変更できます。次に示すのは、このアプローチを使うシリアル化用に JSON.NET (Newtonsoft.Json) を構成する方法の例です。

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

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

組み込みの HTTP モデル

組み込みの HTTP モデルでは、システムは受信した HTTP 要求メッセージを、関数に渡される HttpRequestData オブジェクトに変換します。このオブジェクトは、Headers、Cookies、Identities、URL、メッセージ Body (オプション) を含む、要求からのデータを提供します。このオブジェクトは HTTP 要求の表現ですが、基になる HTTP リスナーまたは受信されたメッセージに直接接続されてはいません。

同様に、関数が返す HttpResponseData オブジェクトも、メッセージ StatusCode、Headers、およびメッセージ Body (オプション) を含む、HTTP 応答を作成するために使用するデータを提供します。

次の例は、HttpRequestData と HttpResponseData の使い方を示しています。

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

Logging

.NET 分離では、ILogger<T> または ILogger インスタンスを使用してログに書き込むことができます。ロガーは、ILogger<T> または ILoggerFactory の依存関係の挿入を通じて取得できます。

public class MyFunction {
    
    private readonly ILogger<MyFunction> _logger;
    
    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    
    [Function(nameof(MyFunction))]
    public void Run([BlobTrigger("samples-workitems/{name}", Connection = "")] string myBlob, string name)
    {
        _logger.LogInformation($"C# Blob trigger function Processed blob\n Name: {name} \n Data: {myBlob}");
    }

}

ロガーは、関数に渡される FunctionContext オブジェクトから取得することもできます。 GetLogger<T> または GetLogger メソッドを呼び出し、ログが書き込まれるカテゴリの名前を表す文字列値を渡します。カテゴリは通常、ログの書き込み元となる特定の関数の名前です。カテゴリについて詳しくは、監視に関する記事をご覧ください。

ILogger<T> と ILogger のメソッドを使用して、LogWarning や LogError などのさまざまなログレベルを記述します。ログレベルについて詳しくは、監視に関する記事をご覧ください。フィルターを登録することで、コードに追加されたコンポーネントのログレベルをカスタマイズできます。

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

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // Registers IHttpClientFactory.
        // By default this sends a lot of Information-level logs.
        services.AddHttpClient();
    })
    .ConfigureLogging(logging =>
    {
        // Disable IHttpClientFactory Informational logs.
        // Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
        logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    })
    .Build();

Program.cs でアプリを構成する一環として、ログにエラーを表示する方法の動作を定義することもできます。既定では、コードによってスローされる例外は、RpcException でラップされる可能性があります。この追加レイヤーを削除するには、ビルダーの構成の一環として、 EnableUserCodeException プロパティを "true" に設定します。

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

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(builder => {}, options =>
    {
        options.EnableUserCodeException = true;
    })
    .Build();

host.Run();

Application Insights

開発者は、分離プロセスアプリケーションがログを直接 Application Insights に出力するように構成できます。この動作は、ホストを介してログをリレーするという既定の動作に代わるものであり、ログの出力方法を開発者が制御できるという理由で推奨されています。

パッケージをインストールする

コードから Application Insights に直接ログを書き込むには、次のパッケージへの参照をプロジェクトに追加してください。

Microsoft.Azure.Functions.Worker.ApplicationInsights バージョン 1.0.0 以降。
Microsoft.ApplicationInsights.WorkerService。

次のコマンドを実行すると、これらの参照をプロジェクトに追加できます。

dotnet add package Microsoft.ApplicationInsights.WorkerService
dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

起動を構成する

パッケージがインストールされている状態で、次の例に示すように AddApplicationInsightsTelemetryWorkerService() と ConfigureFunctionsApplicationInsights() を Program.cs ファイル内でのサービス構成時に呼び出す必要があります。

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

ConfigureFunctionsApplicationInsights() への呼び出しによって ITelemetryModule が追加されますが、これは Functions で定義された ActivitySource をリッスンします。これで、分散トレースのサポートに必要な依存関係テレメトリが作成されます。 AddApplicationInsightsTelemetryWorkerService() の詳細とその使用方法については、「Application Insights for Worker Service アプリケーション」を参照してください。

ログレベルの管理

重要

Functions ホストと分離プロセスワーカーには、ログレベルなどの個別の構成があります。host.json の Application Insights 構成はワーカーからのログには影響しません。同様に、ワーカーコードで行われた構成は、ホストからのログ記録には影響しません。シナリオによって両方のレイヤーでカスタマイズが必要な場合は、両方の場所で変更の適用が必要になる可能性があります。

アプリケーションの残りの部分は引き続き ILogger と ILogger<T> で動作します。ただし、既定では、Application Insights SDK は、警告とそれより深刻なログのみをキャプチャするようにロガーに指示するログフィルターを追加します。この動作を無効にする場合は、サービス構成の一部としてフィルター規則を削除します。

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

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .ConfigureLogging(logging =>
    {
        logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
                == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
        });
    })
    .Build();

host.Run();

パフォーマンスの最適化

このセクションでは、コールドスタートに関するパフォーマンスを向上させるために有効にできるオプションの概要について説明します。

通常アプリでは、最新バージョンのコア依存関係を使用する必要があります。少なくとも、プロジェクトを次のように更新する必要があります。

Microsoft.Azure.Functions.Worker をバージョン 1.19.0 以降にアップグレードします。
Microsoft.Azure.Functions.Worker.Sdk をバージョン 1.16.4 以降にアップグレードします。
アプリで .NET Framework をターゲットにする場合を除き、Microsoft.AspNetCore.App にフレームワーク参照を追加します。

次のスニペットは、プロジェクトファイルのコンテキストでのこの構成を示しています。

  <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.16.4" />
  </ItemGroup>

プレースホルダー

プレースホルダーは、.NET 6 以降をターゲットにするアプリのコールドスタートを改善するプラットフォーム機能です。この最適化を使用するには、次の手順を使用してプレースホルダーを明示的に有効にする必要があります。

前のセクションでの詳細説明のとおりに、最新の依存関係バージョンを使用するようにプロジェクト構成を更新します。
WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED アプリケーション設定を 1 に設定します。これを行うには、次に示す az functionapp config appsettings set コマンドを使用します。
```
az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'
```
この例の中の <groupName> をリソースグループの名前で置き換え、<appName> を関数アプリの名前で置き換えてください。
関数アプリの netFrameworkVersion プロパティがプロジェクトのターゲットフレームワーク (.NET 6 以降である必要があります) と一致していることを確認します。これを行うには、次に示す az functionapp config set コマンドを使用します。
```
az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>
```
この例の中の <framework> も、ターゲットの .NET バージョンに応じて適切なバージョン文字列 (v8.0 など) で置き換えてください。
関数アプリが 64 ビットプロセスを使用するように構成されていることを確認します。これを行うには、次に示す az functionapp config set コマンドを使用します。
```
az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false
```

重要

WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED を 1に設定するときは、他のすべての関数アプリ構成がすべて正しく設定されている必要があります。このとおりでない場合は、関数アプリの起動に失敗する可能性があります。

最適化された Executor

関数 Executor は、呼び出しを実行するプラットフォームのコンポーネントです。このコンポーネントの最適化されたバージョンは、SDK のバージョン 1.16.2 以降で既定で有効になっています。それ以上の構成は必要ありません。

ReadyToRun

関数アプリは ReadyToRun バイナリとしてコンパイルできます。 ReadyToRun は、事前コンパイル形式であり、起動時のパフォーマンスを向上させることができます。これは、従量課金プランで実行される場合にコールドスタートの影響を軽減するのに役立ちます。 ReadyToRun は .NET 6 以降のバージョンで使用可能であり、Azure Functions ランタイムのバージョン 4.0 以降が必要です。

ReadyToRun では、ホスティングアプリのランタイムアーキテクチャに対してプロジェクトをビルドする必要があります。 これらが配置されていない場合は、起動時にアプリでエラーが発生します。 ランタイム識別子を次の表から選択してください。

オペレーティングシステム	アプリは 32 ビットです¹	ランタイム識別子
Windows	正しい	`win-x86`
Windows	いいえ	`win-x64`
Linux	正しい	該当なし (サポートされていません)
Linux	いいえ	`linux-x64`

¹ 他のパフォーマンス最適化の対象となるのは、64 ビットアプリのみです。

Windows アプリが 32 ビットか 64 ビットかをチェックするには、次の CLI コマンドを実行して、<group_name> をリソースグループの名前に、<app_name> をアプリケーションの名前に置き換えます。 "true" の出力は、アプリが 32 ビットであることを示し、"false" は 64 ビットであることを示します。

 az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"

同じ置換を使用して、次のコマンドでアプリケーションを 64 ビットに変更できます。

az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`

プロジェクトを ReadyToRun としてコンパイルするには、<PublishReadyToRun> および <RuntimeIdentifier> 要素を追加して、プロジェクトファイルを更新します。次の例は、Windows 64 ビットの関数アプリに公開するための構成を示しています。

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

<RuntimeIdentifier> をプロジェクトファイルの一部として設定しない場合は、これを発行ジェスチャ自体の一部として構成することもできます。たとえば、Windows 64 ビットの関数アプリでは、.NET CLI コマンドは次のようになります。

dotnet publish --runtime win-x64

Visual Studio では、発行プロファイルの [ターゲットランタイム] オプションが正しいランタイム識別子に設定されている必要があります。既定値である [移植可能] に設定されているときは、ReadyToRun は使用されません。

Azure Functions へのデプロイ

関数コードプロジェクトを Azure にデプロイする場合、それは関数アプリ内または Linux コンテナー内で実行する必要があります。コードをデプロイする前に、関数アプリとその他の必要な Azure リソースが存在している必要があります。

関数アプリを Linux コンテナー内でデプロイすることもできます。詳細については、コンテナーと Azure Functions の使用に関するページを参照してください。

Azure リソースを作成する

関数アプリとその他の必要なリソースを Azure 内で作成するには、次のいずれかの方法を使用します。

Visual Studio: Visual Studio でのコード発行プロセス中にリソースを自動的に作成できます。
Visual Studio Code: Visual Studio Codeがサブスクリプションに接続し、アプリに必要なリソースを作成してから、コードを発行することができます。
Azure CLI: Azure CLI を使用して、必要なリソースを Azure 内で作成できます。
Azure PowerShell: Azure PowerShell を使用して、必要なリソースを Azure 内で作成できます。
デプロイテンプレート: 必要なリソースを Azure にデプロイする作業を、ARM テンプレートと Bicep ファイルを使用して自動化できます。必要な設定がテンプレートに含まれていることを確認してください。
Azure portal: 必要なリソースを Azure portal で作成できます。

アプリケーションの発行

関数アプリとその他の必要なリソースを Azure 内で作成したら、次のいずれかの方法を使用してコードプロジェクトを Azure にデプロイします。

Visual Studio: 単純な手動デプロイを開発中に行います。
Visual Studio Code: 単純な手動デプロイを開発中に行います。
Azure Functions Core Tools: プロジェクトファイルをコマンドラインからデプロイします。
継続的デプロイ: 継続的メンテナンスのためにステージングスロットに頻繁にデプロイする場合に便利です。
デプロイテンプレート: ARM テンプレートまたは Bicep ファイルを使用して、パッケージのデプロイを自動化できます。

詳細については、「Azure Functions のデプロイテクノロジ」を参照してください。

デプロイペイロード

多くのデプロイ方法で zip アーカイブが使用されます。 zip アーカイブを自分で作成する場合は、このセクションに示されている構造に従う必要があります。そうしないと、アプリ起動時にエラーが発生する可能性があります。

デプロイペイロードは、外側の親フォルダーを除いて、dotnet publish コマンドの出力と一致する必要があります。 zip アーカイブは、次のファイルから作成する必要があります。

.azurefunctions/
extensions.json
functions.metadata
host.json
worker.config.json
プロジェクトの実行可能ファイル (コンソールアプリ)
その実行可能ファイルと対になる他のサポートファイルとディレクトリ

これらのファイルはビルドプロセスによって生成され、直接編集することを意図したものではありません。

zip アーカイブをデプロイ用に準備する場合は、出力ディレクトリの内容のみを圧縮し、外側のディレクトリ自体は圧縮しないでください。アーカイブが現在の作業ディレクトリに抽出されたとき、上記のファイルがすぐに表示される必要があります。

デプロイ要件

Azure で .NET 関数を分離ワーカーモデルで実行するには、オペレーティングシステムに応じて次のような要件があります。

Windows
Linux

FUNCTIONS_WORKER_RUNTIME の値が dotnet-isolated に設定されている必要があります。
netFrameworkVersion が目的のバージョンに設定されている必要があります。

関数アプリを Azure 内で作成するときに、前のセクションで示した方法を使用すると、これらの必要な設定が自動的に追加されます。これらのリソースを、自動化のために ARM テンプレートまたは Bicep ファイルを使用して作成するときは、テンプレート内で設定されていることを確認する必要があります。

デバッグ

ローカルで Visual Studio または Visual Studio Code を使用して実行するときは .NET 分離ワーカープロジェクトのデバッグを通常どおりに行うことができます。ただし、期待どおりにならないデバッグシナリオが 2 つあります。

Visual Studio を使用したリモートデバッグ

分離ワーカープロセスアプリは Functions ランタイムの外部で実行されるため、リモートデバッガーを別のプロセスにアタッチする必要があります。 Visual Studio を使用したデバッグの詳細は、「リモートデバッグ」をご覧ください。

.NET Framework をターゲットにするときのデバッグ

分離されたプロジェクトのターゲットが .NET Framework 4.8 の場合、現在のプレビュースコープでは、デバッグを有効にするために手動の手順が必要です。別のターゲットフレームワークを使用する場合、これらの手順は必要ありません。

アプリは、最初の操作として FunctionsDebugger.Enable(); への呼び出しで開始する必要があります。これは、HostBuilder を初期化する前に Main() メソッドで発生します。 Program.cs ファイルは次のようになります。

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

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

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .Build();

            host.Run();
        }
    }
}

次に、.NET Framework デバッガーを使用してプロセスに手動でアタッチする必要があります。 Visual Studio は、分離ワーカープロセスの .NET Framework アプリに対してはまだ自動的にこれを行いません。"デバッグの開始" 操作は避ける必要があります。

プロジェクトディレクトリ (またはそのビルド出力ディレクトリ) で、次を実行します。

func host start --dotnet-isolated-debug

これでワーカーが開始され、プロセスは次のメッセージを表示して停止します。

Azure Functions .NET Worker (PID: <process id>) initialized in debug mode. Waiting for debugger to attach...

ここで、<process id> はワーカープロセスの ID です。これで、Visual Studio を使用して、プロセスに手動でアタッチできるようになりました。この操作の手順については、実行中のプロセスにアタッチする方法に関する記事を参照してください。

デバッガーがアタッチされると、プロセスの実行が再開され、デバッグできるようになります。

プレビュー .NET バージョン

一般公開リリースの前に .NET のバージョンが "プレビュー" または "Go-live" 状態でリリースされることがあります。これらの状態の詳細については、 .NET 公式サポートポリシーを参照してください。

ローカルの Functions プロジェクトから特定のリリースをターゲットにすることもできますが、Azure でホストされている関数アプリでは、そのリリースが利用できない可能性があります。 Azure Functions は、このセクションで説明する "プレビュー" または "Go-live "リリースでのみ使用できます。

Azure Functions は、現在、以下の "プレビュー" または "一般公開" .NET リリースで使用できます。

オペレーティングシステム	.NET のプレビューバージョン
Linux	.NET 9 Preview 7^{1, 2}

¹ .NET 9 を適切にターゲットにするには、プロジェクトでコアパッケージの 2.x バージョンを参照する必要があります。 Visual Studio を使用している場合、.NET 9 にはバージョン 17.12 以降が必要です。

² .NET 9 は Flex Consumption SKU ではまだサポートされていません。

使用できる一般公開リリースの一覧については、サポートされているバージョンを参照してください。

プレビュー .NET SDK の使用

.NET のプレビューバージョンで Azure Functions を使うには、次の方法でプロジェクトを更新する必要があります。

関連する .NET SDK バージョンを開発環境にインストールする
.csproj ファイルの TargetFramework 設定を変更する

Azure の関数アプリにデプロイする場合は、そのアプリでフレームワークが使用できるようにする必要があります。プレビュー期間中、ツールとエクスペリエンスによっては、新しいプレビューバージョンがオプションとして表示されない場合があります。たとえば、Azure portal に含まれているプレビューバージョンが表示されない場合は、REST API、Bicep テンプレート、または Azure CLI を使用して、バージョンを手動で構成することができます。

Windows
Linux

Windows でホストされているアプリの場合は、次の Azure CLI コマンドを使用します。 <groupName> をリソースグループの名前に置き換え、<appName> を関数アプリの名前に置き換えます。 <framework> を適切なバージョン文字列 (たとえば v8.0) に置き換えます。

az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

Linux でホストされているアプリの場合は、次の Azure CLI コマンドを使用します。 <groupName> をリソースグループの名前に置き換え、<appName> を関数アプリの名前に置き換えます。 <version> を適切なバージョン文字列 (たとえば 8.0) に置き換えます。

az functionapp config set -g <groupName> -n <appName> --linux-fx-version "dotnet-isolated|<version>"

.NET のプレビューバージョンを使用する場合の考慮事項

.NET のプレビューバージョンで Functions を使う場合、次の考慮事項に注意してください。

関数を Visual Studio で作成するときは、Visual Studio Preview を使う必要があります。この製品では .NET プレビュー SDK を使用する Azure Functions プロジェクトの構築がサポートされます。
Functions のツールとテンプレートが最新であることを確認します。ツールを更新する手順は次のとおりです。
1. [ツール]>[オプション] に移動し、[プロジェクトおよびソリューション] で [Azure Functions] を選択します。
2. [更新プログラムの確認] を選択し、指示に従って更新プログラムをインストールします。
プレビュー期間中は、開発者の環境の .NET プレビューのバージョンが、ホストされているサービスよりも新しいバージョンであることもあります。これが原因で、関数アプリがデプロイ時に失敗する可能性があります。これに対処するには、使用する SDK のバージョンを global.json で指定します。
1. dotnet --list-sdks コマンドを実行して、ローカル開発で現在使用しているプレビューバージョンを確認します。
2. dotnet new globaljson --sdk-version <SDK_VERSION> --force コマンドを実行します。<SDK_VERSION> はローカルで使用しているバージョンです。たとえば、dotnet new globaljson --sdk-version dotnet-sdk-8.0.100-preview.7.23376.3 --force を実行するとプロジェクトのビルド時に .NET 8 Preview 7 SDK がシステムによって使用されます。

Note

プレビューフレームワークの Just-In-Time 読み込みが理由で、Windows 上で実行される関数アプリのコールドスタート時間が以前の GA バージョンに比べて長くなる可能性があることに注意してください。

次のステップ

Azure Functions のベストプラクティスを確認する

.NET アプリを分離ワーカーモデルに移行する

次の方法で共有

分離ワーカー モデルで C# Azure Functions を実行するためのガイド

分離ワーカー モデルの利点

サポートされているバージョン

プロジェクト構造

パッケージ参照

コア パッケージ

バージョン 2.x (プレビュー)

拡張機能パッケージ

スタートアップと構成

構成

依存関係の挿入

Azure クライアントを登録する

ミドルウェア

JSON シリアル化のカスタマイズ

関数として認識されるメソッド

関数のパラメーター

実行コンテキスト

キャンセル トークン

バインド

入力バインディング

出力バインディング

複数の出力バインディング

SDK タイプ

HTTP トリガー

ASP.NET Core の統合

ASP.NET Core 統合での JSON のシリアル化

組み込みの HTTP モデル

Logging

Application Insights

パッケージをインストールする

起動を構成する

ログ レベルの管理

パフォーマンスの最適化

プレースホルダー

最適化された Executor

ReadyToRun

Azure Functions へのデプロイ

Azure リソースを作成する

アプリケーションの発行

デプロイ ペイロード

デプロイ要件

デバッグ

Visual Studio を使用したリモート デバッグ

.NET Framework をターゲットにするときのデバッグ

プレビュー .NET バージョン

プレビュー .NET SDK の使用

.NET のプレビュー バージョンを使用する場合の考慮事項

次のステップ

フィードバック

その他のリソース

分離ワーカーモデルで C# Azure Functions を実行するためのガイド

分離ワーカーモデルの利点

コアパッケージ

キャンセルトークン

ログレベルの管理

デプロイペイロード

Visual Studio を使用したリモートデバッグ

.NET のプレビューバージョンを使用する場合の考慮事項