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

この記事では、分離されたワーカーモデルを使用した.NETでのAzure Functionsの操作について説明します。このモデルにより、projectは他のランタイムコンポーネントとは別に.NETのバージョンをターゲットにすることができます。サポートされている特定の.NETバージョンの詳細については、サポートされているバージョンを参照してください。

次のリンクを使用して、.NETアイソレーテッドワーカーモデル関数の作成をすぐに開始してください。

始めに	概念	サンプル
Visual Studio Codeを使用するコマンドラインツールの使用 Visual Studio の使用	ホスティングオプション監視	参照試料

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

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

.NET クラスライブラリ関数は、 Functions ホストランタイム (in-process>) と同じプロセス) または分離ワーカープロセスの 2 つのモードで実行できます。 .NET関数が分離されたワーカープロセスで実行されている場合は、次の利点を利用できます。

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

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

2 つのモードの包括的な比較については、「インプロセスと分離ワーカープロセスの間の相違.NET Azure Functionsを参照してください。

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

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

注

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

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

Functions ランタイムのバージョン	分離ワーカーモデル	インプロセスモデル4
関数 4.x1	.NET 10⁵ .NET 9.0 .NET 8.0 .NET Framework 4.8²	.NET 8.0
関数 1.x3	該当なし	.NET Framework 4.8

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

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

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

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

⁵ 従量課金プランでは Linux で 10 個のアプリ.NET実行することはできません。 Linux で実行するには、代わりに Flex 従量課金プランを使用する必要があります。詳細な移行手順については、「従量課金プランアプリを Flex Consumption プランに移行する」を参照してください。

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

Project構成

分離されたワーカーモデルを使用するAzure Functionsの.NET projectは、基本的に、サポートされている .NET ランタイムを対象とする.NETコンソールアプリ projectです。次のファイルは、分離されたproject.NETで必要な基本的なファイルです。

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

完全な例については、.NET 8 サンプル project および .NET Framework 4.8 サンプル project を参照してください。

パッケージ参照

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

コアパッケージ

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

これらのパッケージの最小バージョンは、ターゲットの.NETバージョンによって異なります。

.NET バージョン	`Microsoft.Azure.Functions.Worker`	`Microsoft.Azure.Functions.Worker.Sdk`
.NET 10	2.50.0 以降	2.0.5 以降
.NET 9	2.0.0 以降	2.0.0 以降
.NET 8	1.16.0 以降	1.11.0 以降
.NET Framework	1.16.0 以降	1.11.0 以降

バージョン 2.x

コアパッケージの 2.x バージョンでは、サポートされているフレームワークが変更され、これらの新しいバージョンから新しい.NET API がサポートされます。 2.x バージョンに更新するときは、次の変更に注意してください。

Microsoft.Azure.Functions.Worker.Sdk のバージョン 2.0.0 から始まる：
- SDK には、SDK コンテナービルドの既定の構成が含まれています。
- SDK には、dotnet run がインストールされている場合ののサポートが含まれています。 Windows では、NPM 以外のメカニズムを使用して Core Tools をインストールします。
Microsoft.Azure.Functions.Worker バージョン 2.0.0 以降:
- このバージョンでのサポートが追加されます。このガイドの例の中には、を使用する代替方法を示すタブが含まれているものがあります。これらの例には 2.x バージョンが必要です。
- 開発環境で実行するときは、サービスプロバイダースコープ検証が既定で含まれます。この動作は、ASP.NET Coreと一致します。
- オプションは既定で有効化されます。このプロパティは、現在では非推奨となっています。
- オプションは既定で有効化されます。このオプションが有効のときは、コレクションを表すトリガーペイロードには常に空のエントリが含まれます。たとえば、本文なしでメッセージが送信された場合でも、トリガーデータのに空のエントリが存在します。この空のエントリを含めることによって、関数が参照するメタデータ配列との相互参照が容易になります。この動作を無効にするには、サービス構成の中でをに設定します。
- クラスの名前がに変更されます。この名前変更の結果、をインスタンスに対して使用するときのあいまい呼び出しエラーが回避されます。
- を使用するアプリの場合、メソッドは状態コードをに設定しなくなりました。 1.x では、この挙動によって、設定した他のエラーコードを上書きします。
2.x バージョンでは、.NET 5 TFM サポートが終了します。

拡張機能パッケージ

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

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

スタートアップと構成

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

IHostApplicationBuilder
IHostBuilder

を使用するには、アプリでバージョン 2.x 以降のコアパッケージを使用する必要があります。

次のコードは IHostApplicationBuilder パイプラインの例です。

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.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://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs
        LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

var host = builder.Build();

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

ASP.NET Core統合を使用する場合は、builder.ConfigureFunctionsWebApplication()を呼び出します。
F# を使用してアプリケーションをプログラミングする場合は、バインド拡張機能の登録が必要になる可能性があります。 F# アプリでこれらの拡張機能を使用する場合は、Blobs 拡張機能、Tables 拡張機能、および Cosmos DB 拡張機能のセットアップドキュメントを参照してください。
プロジェクトに必要なサービスまたはアプリ設定を構成します。詳細については「構成」を参照してください。
Application Insights を使用する予定の場合は、とをビルダーのプロパティに対して呼び出す必要があります。詳細については、「Application Insights」を参照してください。

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

IHostApplicationBuilder を使用すると、完全に初期化されたインスタンスがビルドされて返されます。このインスタンスを非同期で実行して関数アプリを起動します。

await host.RunAsync();

次のコードは 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://learn.microsoft.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();

スタートアップコードに関する考慮事項:

上のを呼び出す前に、以下の操作を行う必要があります。
- ConfigureFunctionsWebApplication() を使用している場合は、それ以外の場合は ConfigureFunctionsWorkerDefaults() を呼び出します。これらのオプションの詳細については、「HTTP トリガー」を参照してください。
  アプリケーションのプログラミングに F# を使用する場合は、一部のトリガーおよびバインド拡張機能に追加の構成が必要になります。 F# アプリでこれらの拡張機能を使用する場合は、Blobs 拡張機能、Tables 拡張機能、および Cosmos DB 拡張機能のセットアップドキュメントを参照してください。
- プロジェクトに必要なサービスまたはアプリ設定を構成します。詳細については「構成」を参照してください。
  Application Insights を使用する場合は、デリゲートでとを呼び出す必要があります。詳細については、「Application Insights」を参照してください。
projectが Framework 4.8 .NETターゲットの場合は、HostBuilder を作成する前に FunctionsDebugger.Enable(); も追加する必要があります。これは、メソッドの最初の行である必要があります。詳細については、「.NET Framework を対象とする場合のデバッグ」を参照してください。
この例には、スタートアップコードでは省略可能な依存関係の挿入が含まれています。依存関係の挿入には、も必要です。詳細については、依存性の注入に関するページを参照してください。
HostBuilder は、完全に初期化されたインスタンスをビルドして返します。関数アプリを起動するには、このインスタンスを非同期的に実行します。
```
await host.RunAsync();
```

構成

使用するビルダーの種類によって、アプリケーションの構成方法が決まります。

IHostApplicationBuilder
IHostBuilder

メソッドを使用して、関数アプリの実行に必要な設定を追加します。このメソッドには、次の機能が含まれています。

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

ビルダーパイプラインにaccessしているため、初期化中にアプリ固有の構成を設定できます。拡張メソッドをビルダーのプロパティに対して呼び出すと、コードに必要な任意の構成ソースを追加できます。アプリケーション構成の詳細については、ASP.NET Core の構成を参照してください。

ConfigureFunctionsWorkerDefaults メソッドを使用して、関数アプリの実行に必要な設定を追加します。このメソッドには、次の機能が含まれています。

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

.ConfigureFunctionsWorkerDefaults()

ホストビルダーパイプラインにaccessしているため、初期化中にアプリ固有の構成を設定できます。 HostBuilder で ConfigureAppConfiguration メソッドを 1 回以上呼び出して、コードに必要な構成ソースを追加します。 app configuration の詳細については、「ASP.NET Core の Configuration」を参照してください。

これらの構成は、作成したワーカーコードにのみ適用されます。 Functions ホストまたはトリガーとバインドの構成には直接影響しません。関数のホストまたはトリガーとバインドの構成を変更するには、 host.json ファイルを使用します。

注

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

依存関係の挿入

分離ワーカーモデルでは、サービスを挿入するために標準の.NETメカニズムが使用されます。

IHostApplicationBuilder
IHostBuilder

IHostApplicationBuilderを使用する場合は、Services プロパティを使用して、IServiceCollection にアクセスします。次の例では、シングルトンサービスの依存関係を挿入します。

builder.Services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();

を使用するときは、ConfigureServices をホストビルダーに対して呼び出し、IServiceCollection の拡張メソッドを使用して特定のサービスを挿入します。次の例では、シングルトンサービスの依存関係を挿入します。

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

このコードではが必要です。詳細については、ASP.NET Core での Dependency インジェクションに関するページを参照してください。

クライアントAzure登録する

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

IHostApplicationBuilder
IHostBuilder

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(builder.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });

builder.Build().Run();

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 の内容を 1 つのコンテナーから別のコンテナーにストリームとしてコピーする方法を示しています。

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

    }
}

この例のは依存関係の挿入によっても取得されるため、自動的に登録されます。ログ記録の構成オプションの詳細については、「ログ記録」を参照してください。

ヒント

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

ミドルウェア

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

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

IHostApplicationBuilder
IHostBuilder

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

var builder = FunctionsApplication.CreateBuilder(args);

// Register our custom middlewares with the worker
builder
    .UseMiddleware<ExceptionHandlingMiddleware>()
    .UseMiddleware<MyCustomMiddleware>()
    .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";
    });

builder.Build().Run();

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

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

次の FunctionContext分離モデルでミドルウェアを簡単に操作できます。

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

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

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

このミドルウェアは、特定の要求ヘッダー () の有無を確認します。ヘッダーが存在する場合、ミドルウェアはヘッダー値を使用して応答ヘッダーにスタンプを付けます。それ以外の場合は、新しい GUID 値が生成され、その値を使用して応答ヘッダーがスタンプされます。

ヒント

後に応答ヘッダーを設定する前に示したパターンは、すべてのシナリオで確実に動作しない可能性があります。この問題は、ASP.NET Core統合を使用する場合、または応答ストリームが既に送信されている可能性がある特定のランタイム構成で特に当てはまります。ヘッダーが正しく設定されていることを確認するには、関数の実行完了後にミドルウェアで変更するのではなく、から応答を取得し、応答が関数から返される前にヘッダーを設定することを検討してください。

関数アプリでカスタムミドルウェアを使用するより完全な例については、custom ミドルウェアリファレンスサンプルを参照してください。

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

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

IHostApplicationBuilder
IHostBuilder

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
    {
        jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
        jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
        jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

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

builder.Build().Run();

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

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 パッケージをインストールします。次に、サービス登録で、構成のプロパティを再割り当てします。次の例は、を使用してこの構成を示していますが、でも機能します。

IHostApplicationBuilder
IHostBuilder

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

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

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

builder.Build().Run();

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(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

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

属性は、関数のエントリポイントとしてメソッドをマークします。名前は、project内で一意であり、文字で始まり、文字、数字、_、および - (最大 127 文字) のみを含む必要があります。 Projectテンプレートでは、多くの場合、Run という名前のメソッドが作成されますが、メソッド名には任意の有効な C# メソッド名を指定できます。このメソッドは、パブリッククラスのパブリックメンバーである必要があります。依存関係の挿入を介してサービスを渡すことができるように、通常はインスタンスメソッド必要があります。

関数のパラメーター

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

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

実行コンテキスト

分離されたワーカーモデルでは、ワーカープロセスは FunctionContext オブジェクトを関数メソッドに渡します。このオブジェクトを使用してILogger インスタンスを取得するためには、categoryName 文字列を指定してGetLogger メソッドを呼び出し、ログに書き込むことができます。このコンテキストを使用すると、依存関係の挿入を使用する必要なくを取得できます。詳細については、ログ記録に関するページを参照してください。

キャンセルトークン

関数は 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);
    }
}

取り消しにつながるシナリオ

キャンセルトークンは、関数の呼び出しが取り消されたときに通知されます。いくつかの理由で取り消しが発生する可能性があり、それらの理由は、使用されているトリガーの種類によって異なります。一般的な理由を以下にいくつか示します。

クライアントの切断: 関数を呼び出しているクライアントが切断されます。この理由は、HTTP トリガー関数の場合に最も可能性が高いです。
関数アプリの再起動: 呼び出しが要求されると同時に、ユーザーまたはプラットフォームが関数アプリを再起動 (または停止) します。再起動は、ワーカーインスタンスの移動、ワーカーインスタンスの更新、またはスケーリングが原因で発生する可能性があります。

取り消しに関する考慮事項

再起動イベント中の実行中の呼び出しは、トリガーされた方法に応じて再試行される場合があります。詳細については、再試行に関するドキュメントを参照してください。
ホストは、キャンセルトークンが取り消される前であっても、ホストが呼び出し要求をワーカーに送信できる前に、ワーカーに呼び出しを送信します。
事前に取り消された呼び出しをワーカーに送信しない場合は、プロパティをファイルに追加して、この動作を無効にします。

この例では、このプロパティを使用するファイルを示します。
```
{
    "version": "2.0",
    "SendCanceledInvocationsToWorker": "false"
}
```
をに設定すると、次のログで例外が発生する可能性があります。

取り消しが要求されました。 ID '{invocationId}' の呼び出し要求は取り消され、ワーカーに送信されません。

この例外は、ホストがワーカーに着信呼び出し要求を送信する前に、キャンセルトークンが取り消されたときに発生します (前述のいずれかのイベントの結果)。この例外は無視しても問題ありません。が場合に想定されます。

非同期プログラミング

分離された.NETワーカーは、カスタム SynchronizationContextを設定しません。つまり、この変数は関数の実行中に設定されます。 awaitの後、スレッドプールで継続がスケジュールされます。これは、標準的な.NET動作です。

抑制するものがないため、関数コードでそれを使用しても実用的な効果はありません。分離されたワーカープロセスは標準.NET汎用ホスト (コンソールアプリ) として実行されるため、ASP.NET Coreまたはコンソールアプリケーションで想定されるのと同じ非同期/待機動作がここに適用されます。これは、.NET Framework (net48) 分離ワーカーアプリにも当てはまります。ワーカープロセスは常に HostBuilder を使用するコンソール実行可能ファイルであるためです。

注

Durable Functions オーケストレーターには、独自のスレッド制約があります。オーケストレーター再生スレッドは継続を実行する必要があるため、オーケストレーター関数またはオーケストレーターミドルウェアでを使用すると、オーケストレーションの実行が妨げられる可能性があります。詳細については、Durable Functions コード制約を参照してください。

バインド

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

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

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

入力バインディング

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

出力バインディング

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

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([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}"};

    _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 拡張機能の version 3.2.0 以降、および ASP.NET Core 拡張機能の version 1.3.0 以降を使用する場合に使用できます。

SDK タイプ

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

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

マシンで SDK の種類をローカルでテストする場合は、Azure Functions Core Tools バージョン 4.0.5000 以降も使用する必要があります。コマンドを使用して、現在のバージョンを確認できます。

また、各バインディング拡張機能には、拡張機能のリファレンス記事で説明されている、独自の最小バージョン要件もあります。現在、これらのバインド拡張機能は SDK の種類をサポートしています。

Extension	種類	サポートレベル
Azure Blob Storage	`BlobClient` `BlobContainerClient` `BlockBlobClient` `PageBlobClient` `AppendBlobClient`	トリガー: GA 入力: GA
Azure Cosmos DB	`CosmosClient` `Database` `Container`	入力: GA
Azure Event Grid	`CloudEvent` `EventGridEvent`	トリガー: GA
Azure Event Hubs	`EventData` `EventHubProducerClient`	トリガー: GA
Azure Queue Storage	`QueueClient` `QueueMessage`	トリガー: GA
Azure Service Bus	`ServiceBusClient` `ServiceBusReceiver` `ServiceBusSender` `ServiceBusMessage`	トリガー: GA
Azure Table Storage	`TableClient` `TableEntity`	入力: GA

SDK の種類に関する考慮事項:

トリガーデータに依存するバインド式を使用するとき、トリガー自体の SDK の型は使用できません。
SDK の種類を使用する可能性がある出力シナリオでは、出力バインディングを使用するのではなく、SDK クライアントを直接作成して操作します。
Azure Cosmos DB トリガーは、Azure Cosmos DB 変更フィードを使用し、変更フィード項目を JSON シリアル化可能な型として公開します。そのため、このトリガーでは SDK の種類はサポートされていません。

HTTP トリガー

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

ASP.NET Core開発者になじみのある概念を使用するASP.NET Core統合モデル
組み込みモデル。追加の依存関係は不要であり、カスタム型が HTTP 要求と応答に使用されます。このアプローチは、以前の.NETのアイソレーテッドワーカーアプリとの互換性を確保するために維持されています。

ASP.NET Core統合

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

注

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

HTTP の ASP.NET Core統合を有効にするには:

プロジェクトにMicrosoft.Azure.Functions.Worker.Extensions.Http.AspNetCoreパッケージのバージョン1.0.0以降を追加します。
次の特定のパッケージバージョンを使用するようにprojectを更新します。
- Microsoft。Azure。Functions.Worker.Sdk バージョン 1.11.0。以降
- Microsoft。Azure。Functions.Worker バージョン 1.16.0 以降。
ファイルの中で、を呼び出すようにホストビルダーの構成を更新します。このメソッドは、他のメソッドを使用する場合にを置き換えます。次の例は、他のカスタマイズを行わない最小限のセットアップを示しています。
- IHostBuilder
- IHostApplicationBuilder
```
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Hosting;

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

host.Run();
```
注

アプリケーションは、Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore バージョン 2.0.0 以降を参照する必要があります。これにより、IHostApplicationBuilder との ASP.NET Core 統合を使用できます。
```
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();    

builder.Build().Run();
```
ASP.NET Core型を使用するように、既存の HTTP によってトリガーされる関数を更新します。この例では、標準のとが単純な "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 トリガーに使われるシリアル化の動作をカスタマイズするには、サービス登録の一部としての呼び出しを含める必要があります。返されたIMvcBuilderを使用して、ASP.NET Coreの JSON シリアル化設定を変更できます。

ASP.NET 統合の使用中は、引き続き HttpRequestData と HttpResponseData を使用できますが、ほとんどのアプリでは、代わりに HttpRequest と IActionResult を使用することをお勧めします。 HttpRequestData / HttpResponseData を使用しても、ASP.NET Coreシリアル化レイヤーは呼び出されません。代わりに、アプリの general worker シリアル化構成に依存します。ただし、ASP.NET Core統合が有効になっている場合でも、構成の追加が必要になる場合があります。 ASP.NET Coreの既定の動作は、同期 IO を禁止することです。などの非同期 IO をサポートしていないカスタムシリアライザーを使用するには、を構成してアプリケーションの同期 IO を有効にする必要があります。

次の例は、JSON.NET (Newtonsoft.Json) と Microsoft.AspNetCore.Mvc.NewtonsoftJson NuGet パッケージを使用してシリアル化を行うために構成する方法を示しています。

IHostApplicationBuilder
IHostBuilder

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Services.AddMvc().AddNewtonsoftJson();

// Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
// builder.Services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);

builder.Build().Run();

using Microsoft.AspNetCore.Server.Kestrel.Core;
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();

        // Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
        // services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);
    })
    .Build();
host.Run();

組み込みの HTTP モデル

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

重要

を使用する場合、HTTP 要求の本文をストリームにすることはできません。たとえば、要求にヘッダーがあり、ヘッダーがない場合、オブジェクトのプロパティは null ストリームになります。ストリーミング HTTP 要求を操作する必要がある場合は、代わりに ASP.NET Core 統合モデルを使用することを検討してください。

同様に、この関数は HttpResponseData オブジェクトを返します。このオブジェクトは、メッセージ StatusCode、Headers、必要に応じてメッセージ Bodyなど、HTTP 応答の作成に使用されるデータを提供します。

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

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

ログ記録

ログに書き込むには、またはインスタンスを使用します。またはの依存関係挿入を通じてロガーを取得できます。

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

}

注

前の例のように、クラスコンストラクターにを挿入すると、ログカテゴリはそのクラスの完全修飾名 ( など) に自動的に設定されます。これらのカテゴリ名には、 (ピリオド) 文字が含まれます。 Linux で関数アプリをホストする場合、環境変数を使用して、期間を含むカテゴリのログレベルをオーバーライドすることはできません。この制限を回避するには、代わりにコードまたはファイルします。

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

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

IHostApplicationBuilder
IHostBuilder

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

// Registers IHttpClientFactory.
// By default this sends a lot of Information-level logs.
builder.Services.AddHttpClient();

// Disable IHttpClientFactory Informational logs.
// Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    
builder.Build().Run();

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

でアプリを構成する一環として、ログにエラーを表示する方法の動作を定義することもできます。既定の動作は、使用するビルダーの種類によって異なります。

IHostApplicationBuilder
IHostBuilder

を使用すると、コードによってスローされる例外は、変更なしでシステムを通過します。他の構成は必要ありません。

を使用すると、開発中のコードがスローした例外が、最終的に内にラップされる可能性があります。この追加のレイヤーを削除するには、ビルダーの構成の一環として、プロパティをに設定します。

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 の直接統合を構成します。これらのログの出力方法を制御できるためです。

Application Insights 統合は、すべてのセットアップエクスペリエンスで既定では有効になっていません。一部のテンプレートでは、必要なパッケージとスタートアップコードがコメントアウトされた Functions プロジェクトが作成されます。Application Insights 統合を使用する場合は、Program.cs とprojectの .csproj ファイルでこれらの行のコメントを解除します。このセクションの残りの部分の手順で、統合を有効にする方法についても説明します。

開発中プロジェクトが Aspire オーケストレーションの一部である場合は、Aspire オーケストレーションは監視の目的で代わりに OpenTelemetry を使用します。アスパイアプロジェクト内で Application Insights の直接統合を有効にしないでください。代わりに、Azure Monitor OpenTelemetry エクスポーターを、サービスの既定値projectの一部として構成します。 Functions projectが、アスパイアコンテキストで Application Insights 統合を使用している場合、起動時にアプリケーションエラーが発生します。

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

コードから Application Insights に直接ログを書き込むには、projectでこれらのパッケージへの参照を追加します。

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

次のコマンドを実行して、これらの参照をprojectに追加します。

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

起動を構成する

パッケージをインストールした後、次の例に示すように、ファイルのサービス構成中にとを呼び出します。

IHostApplicationBuilder
IHostBuilder

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

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

の呼び出しにより、Functions で定義されたをリッスンするが追加されます。このモジュールでは、分散トレースをサポートするために必要な依存関係テレメトリを作成します。 AddApplicationInsightsTelemetryWorkerService()とその使用方法の詳細については、「ワーカーサービスアプリケーション用のアプリケーション分析情報を参照してください。

ログレベルの管理

重要

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

アプリケーションの残りの部分は引き続きとで動作します。ただし、既定では、Application Insights SDK は、警告とそれより深刻なログのみを取り込むようにロガーに指示するログフィルターを追加します。分離ワーカープロセスでは、次のいずれかの方法でログレベルを構成できます。

構成方法	メリット
コード内	ホスト側とワーカー側の構成をより明確に分離します。
の使用	コードを変更しなくても、カテゴリごとに異なるログレベルを設定する場合に便利です。

コードベース
コードベース
Configuration
IHostBuilder

既定の動作を無効にし、すべてのログレベルをキャプチャするには、サービス構成の一部としてフィルター規則を削除します。

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

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

builder.Build().Run();

既定の動作を無効にし、すべてのログレベルをキャプチャするには、サービス構成の一部としてフィルター規則を削除します。

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

は、ファイルから構成を自動的に読み込みます。ファイルにログ記録の構成を追加できます。

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

この構成は、ビルダーの作成時に自動的に適用されます。では、追加のコード変更は必要ありません。

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

を使用すると、などの構成ファイルは自動的に読み込まれません。これらのファイルを読み込むには、を使用します。

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

var host = new HostBuilder()
    .ConfigureAppConfiguration(config =>
    {
        config.SetBasePath(Directory.GetCurrentDirectory())
              .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
              .AddEnvironmentVariables();
    })
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

次に、次の内容を含む appsettings.json ファイルを project ルートに作成します。

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.Azure.Functions.Worker": "Information"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

ヒント

または、の代わりにを使用することもできます。このメソッドは、、環境変数、およびその他のソースから構成を自動的に読み込みます。ただし、 FunctionsApplication.CreateBuilder() は、Functions worker ( の呼び出しを含む) を自動的に構成し、構成ファイルを読み込むため、新しいプロジェクトに推奨されるアプローチです。

ログ記録の構成の詳細については、「 .NET およびワーカーサービスアプリケーションのアプリケーションのログ記録を参照してください。

パフォーマンスの最適化

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

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

Microsoft.Azure.Functions.Worker をバージョン 1.19.0 以降にアップグレードします。
Microsoft.Azure.Functions.Worker.Sdk をバージョン 1.16.4 以降にアップグレードします。
Microsoft.AspNetCore.App へのフレームワーク参照を追加します(アプリがフレームワーク .NETを対象とする場合を除く)。

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

  <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 以降を対象とするアプリのコールドスタートを改善するプラットフォーム機能です。この最適化を使用するには、次の手順に従ってプレースホルダーを明示的に有効にする必要があります。

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

重要

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

最適化された Executor

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

ReadyToRun

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

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

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

1 他のパフォーマンス最適化の対象となるのは、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`

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

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

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

dotnet publish --runtime win-x64

Visual Studioで、発行プロファイルの Target Runtime オプションを適切なランタイム識別子に設定します。既定値である [移植可能] に設定されているときは、ReadyToRun は使用されません。

Azure Functionsにデプロイする

Azureに関数コード projectをデプロイする場合は、関数アプリまたは 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に必要なリソースを作成します。
デプロイテンプレート: ARM テンプレートと Bicep ファイルを使用して、Azureするために必要なリソースのデプロイを自動化します。必要な設定がテンプレートに含まれていることを確認してください。
Azure portal: Azure portalに必要なリソースを作成します。

アプリケーションの発行

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

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

詳細については、「deployment technologies in Azure Functions」を参照してください。

デプロイペイロード

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

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

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

ビルドプロセスによってこれらのファイルが生成されるため、直接編集しないでください。

ヒント

Core Tools のコマンドを使用して、デプロイ用の zip アーカイブを正しく生成できます。のサポートは現在プレビュー段階です。

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

デプロイ要件

Azureの分離ワーカーモデルで.NET関数を実行するには、いくつかの要件を満たす必要があります。要件は、オペレーティングシステムによって異なります。

ウィンドウズ
リナックス

FUNCTIONS_WORKER_RUNTIMEをに設定します。
netFrameworkVersion を目的のバージョンに設定します。

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

Aspire

アスパイアは、クラウドでの分散アプリケーションの開発を簡素化するオピニオンスタックです。分離されたワーカーモデルプロジェクトは、アスパイア 13 オーケストレーションに参加させることができます。詳細については、「Azure Functions with Aspire」を参照してください。

デバッグ

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

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

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

.NET Framework を対象とする場合のデバッグ

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

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

IHostApplicationBuilder
IHostBuilder

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 = FunctionsApplication
                .CreateBuilder(args)
                .Build();

            host.Run();
        }
    }
}

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 アプリに対してこれを自動的に行いません。また、"デバッグの開始" 操作は避ける必要があります。

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

func host start --dotnet-isolated-debug

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

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

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

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

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

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

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

Azure Functionsは現在、"プレビュー" または "ライブ開始" の.NETリリースでは動作しません。使用できる一般公開リリースの一覧については、サポートされているバージョンを参照してください。

プレビュー .NET SDK の使用

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

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

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

ウィンドウズ
リナックス

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

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

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

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

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

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

Visual Studioで関数を作成する場合は、Visual Studio Insiders を使用する必要があります。これは、.NET プレビュー SDK を使用したAzure Functions プロジェクトの構築をサポートします。
Functions のツールとテンプレートが最新であることを確認します。ツールを更新する手順は次のとおりです。
1. ToolsOptions Projects and SolutionsMore Settings の下にある Azure Functions を選択します。
2. [更新プログラムの確認] を選択し、指示に従って更新プログラムをインストールします。
プレビュー期間中は、開発環境の.NET プレビューのバージョンが、ホストされているサービスよりも新しいバージョンになる場合があります。これが原因で、関数アプリがデプロイ時に失敗する可能性があります。これに対処するには、使用する SDK のバージョンをで指定します。
1. コマンドを実行して、ローカル開発で現在使用しているプレビューバージョンを確認します。
2. コマンドを実行します。はローカルで使用しているバージョンです。たとえば、dotnet new globaljson --sdk-version dotnet-sdk-10.0.100-preview.5.25277.114 --force により、プロジェクトのビルド時にシステムは .NET 10 プレビュー5 SDK を使用します。

注

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

次のステップ

Azure Functions

.NET アプリを分離されたワーカーモデルに移行します

アスパイアとの統合

フィードバック

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

Last updated on 2026-03-05