.NET 11 の ASP.NET Core の新機能

この記事では、.NET 11 の ASP.NET Core における最も重要な変更点と、関連するドキュメントへのリンクについて説明します。

この記事は、新しいプレビューリリースが利用可能になると更新されます。

Blazor

このセクションでは、Blazorの新機能について説明します。

新しい `DisplayName` コンポーネントと `[Display]` 属性と `[DisplayName]` 属性のサポート

DisplayName コンポーネントを使用して、メタデータ属性のプロパティ名を表示できます。

[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }

モデルクラスプロパティの [Display] 属性がサポートされています。

[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }

2 つの方法のうち、 [Display] 属性を使用することをお勧めします。これにより、追加のプロパティを使用できるようになります。 [Display]属性を使用すると、ローカライズ用のリソースの種類を割り当てることもできます。両方の属性が存在する場合、 [Display] は [DisplayName]よりも優先されます。どちらの属性も存在しない場合、コンポーネントはプロパティ名にフォールバックします。

ラベルまたはテーブルヘッダーで DisplayName コンポーネントを使用します。

<label>
    <DisplayName For="@(() => Model!.ProductionDate)" />
    <InputDate @bind-Value="Model!.ProductionDate" />
</label>

Blazor Web スクリプトのスタートアップオプションの形式が、Blazor Server および Blazor WebAssembly スクリプトでサポートされるようになりました

Blazor Web App に渡される blazor.web.js スクリプト (Blazor.start()) オプションオブジェクトは、.NET 8 のリリース以降、次の形式を使用します。

Blazor.start({
  ssr: { ... },
  circuit: { ... },
  webAssembly: { ... },
});

これで、 Blazor Server (blazor.server.js) スクリプトと Blazor WebAssembly (blazor.webassembly.js) スクリプトで同じオプション形式を使用できるようになりました。

次の例は、以前のオプション形式を示しています。これは引き続きサポートされています。

Blazor.start({
  loadBootResource: function (...) {
      ...
    },
  });

前の例で新しくサポートされたオプションの形式は次のとおりです。

Blazor.start({
  webAssembly: {
    loadBootResource: function (...) {
      ...
    },
  },
});

詳しくは、「ASP.NET Core Blazor の起動」をご覧ください。

新しい `BasePath` コンポーネント

Blazor Web Appでは、新しい BasePath コンポーネント (<BasePath />) を使用して、アプリのアプリのベースパス (<base href>) HTML タグを自動的にレンダリングできます。詳細については、「ASP.NET コアBlazor アプリベースパス」を参照してください。

JS コンポーネントから削除されたインライン `NavMenu` イベントハンドラー

ナビゲーションリンクの表示を切り替えるインライン JS イベントハンドラーが、NavMenu プロジェクトテンプレートのBlazor Web App コンポーネントに存在しなくなりました。プロジェクトテンプレートから生成されたアプリでは、併置された JS モジュールアプローチを使用して、レンダリングされたページのナビゲーションバーを表示または非表示にできるようになりました。新しいアプローチでは、インラインの安全でないハッシュを CSP に含める必要がないため、JSが向上します。

ナビゲーションバートグルツールの新しい JS モジュールアプローチの採用など、既存のアプリを .NET 11 に移行するには、「 .NET 10 の ASP.NET Core から .NET 11 の ASP.NET Core への移行」を参照してください。

`NavigateTo`相対ナビゲーションのサポートと`NavLink`

RelativeToCurrentUriとfalse コンポーネントの新しいNavigationManager.NavigateTo パラメーター (既定値: NavLink) を使用すると、アプリのベース URI ではなく、現在のページパスに対する URI に移動できます。

次の入れ子になったエンドポイントについて考えてみましょう。

/docs
- /getting-started
  - /installation
  - /configuration

ブラウザーの URI が/docs/getting-started/installationされ、ユーザーを/docs/getting-started/configurationに移動する場合、NavigateTo("/configuration")/configurationの相対パスではなく、アプリのルートにある/docs/getting-started/configurationにリダイレクトされます。目的のナビゲーションにRelativeToCurrentUriまたはNavigateToを使用してNavLinkを設定します。

Navigation.NavigateTo("/configuration", new NavigationOptions
{
    RelativeToCurrentUri = true
});

<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>

静的サーバー側レンダリング中に HTTP 要求間で一時データを保持する (静的 SSR)

静的サーバー側レンダリング (静的 SSR) 中に HTTP 要求間で一時データを保持するために、 Blazor は TempData をサポートします。 TempData は、フォームの送信後にメッセージをフラッシュする、リダイレクト中にデータを渡す (POST-Redirect-GET パターン)、1 回限りの通知などのシナリオに最適です。

TempData は、アプリのAddRazorComponents ファイルでProgramが呼び出され、[CascadingParameter]属性を持つカスケード値として提供される場合に使用できます。

[CascadingParameter]
public ITempData? TempData { get; set; }

詳細については、「 ASP.NET Core Blazor サーバー側の状態管理」を参照してください。

Blazor Hybrid

このセクションでは、Blazor Hybridの新機能について説明します。

リリースノートは、プレビュー機能が利用可能になると、このセクションに表示されます。

SignalR

このセクションでは、SignalRの新機能について説明します。

最小限の API

このセクションでは、最小限の API の新機能について説明します。

OpenAPI

このセクションでは、OpenAPI の新機能について説明します。

バイナリファイルの応答について説明する

ASP.NET Core 11 では、バイナリファイルの応答を返す操作に対して OpenAPI の説明を生成するためのサポートが導入されています。このサポートにより、 FileContentResult 結果の種類が、 type: string と format: binaryを持つ OpenAPI スキーマにマップされます。

最小限の API
Controllers

Produces<T>のTでFileContentResult拡張メソッドを使用して、応答の種類とコンテンツタイプを指定します。

app.MapPost("/filecontentresult", () =>
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);

ProducesResponseType<T>のTでFileContentResult属性を使用して、応答の種類とコンテンツタイプを指定します。

[HttpPost("filecontentresult")]
[ProducesResponseType<FileContentResult>(StatusCodes.Status200OK, MediaTypeNames.Application.Octet)]
public IActionResult PostFileContentResult()
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return new FileContentResult(content, MediaTypeNames.Application.Octet);
}

生成された OpenAPI ドキュメントでは、エンドポイントの応答が次のように記述されています。

responses:
  '200':
    description: OK
    content:
      application/octet-stream:
        schema:
          $ref: '#/components/schemas/FileContentResult'

FileContentResultは、次のようにcomponents/schemasで定義されます。

components:
  schemas:
    FileContentResult:
      type: string
      format: binary

OpenAPI 3.2.0 のサポート (破壊的変更)

Microsoft.AspNetCore.OpenApi Microsoft.OpenApi 3.3.1 への更新された依存関係により、OpenAPI 3.2.0 がサポートされるようになりました。この更新プログラムには、基になるライブラリからの破壊的変更が含まれています。詳細については、 Microsoft.OpenApi アップグレードガイドを参照してください。

OpenAPI 3.2.0 ドキュメントを生成するには、 AddOpenApiを呼び出すときにバージョンを指定します。

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});

以降の更新では、ストリーミングイベントの項目スキーマのサポートなど、3.2.0 仕様の新機能を利用します。

@baywetさん、この貢献をありがとうございます！

認証と承認

このセクションでは、認証と認可の新機能について説明します。

`TimeProvider` ASP.NET Core でのサポート Identity

ASP.NET Core Identityでは、すべての時間関連の操作にTimeProviderとDateTimeではなく、DateTimeOffsetが使用されるようになりました。この変更により、 Identity コンポーネントのテストが容易になり、テストや特殊なシナリオでの時間の制御が向上します。

次の例は、TimeProvider機能のテストに偽のIdentityを使用する方法を示しています。

// In tests
var fakeTimeProvider = new FakeTimeProvider(
    new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));

services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();

// Identity will now use the fake time provider

TimeProviderを使用すると、トークンの有効期限、ロックアウト期間、セキュリティスタンプの検証など、時間の影響を受けやすいIdentity機能の決定論的なテストをより簡単に作成できます。

認証子からパスキーの表示名を推測する

ASP.NET Core Identity は、AAGUID (Authenticator Attestation GUID) に基づいてパスキーのフレンドリーな表示名を自動で推論するようになりました。組み込みのマッピングは、Google パスワードマネージャー、iCloud キーチェーン、Windows Hello、1Password、Bitwarden など、最も一般的に使用されるパスキー認証子に含まれています。

既知の認証子の場合、ユーザーに確認を求めることなく、名前が自動的に割り当てられます。不明な認証子の場合、ユーザーは名前変更ページにリダイレクトされます。プロジェクトの PasskeyAuthenticators ディクショナリにエントリを追加して、マッピングを拡張します。

Miscellaneous

このセクションでは、.NET 11 のその他の新機能について説明します。

`IOutputCachePolicyProvider` インターフェイス

.NET 11 の ASP.NET Core には、カスタム出力キャッシュポリシー選択ロジックを実装するための [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)' インターフェイスが用意されています。このインターフェイスを使用すると、アプリは既定のベースキャッシュポリシーを決定し、名前付きポリシーの存在を確認し、ポリシーを動的に解決する必要がある高度なシナリオをサポートできます。たとえば、外部構成ソース、データベースからのポリシーの読み込み、テナント固有のキャッシュ規則の適用などがあります。

次のコードは、 IOutputCachePolicyProvider インターフェイスを示しています。

public interface IOutputCachePolicyProvider
{
    IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
    ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}

このたびは@lqliveさんのご投稿をいただき、ありがとうございます。

WSL での開発証明書の自動信頼

開発証明書のセットアップで、WSL (Linux 用 Windows サブシステム) 環境の証明書が自動的に信頼されるようになりました。 WSL で dotnet dev-certs https --trust を実行すると、WSL 環境と Windows の両方で証明書が自動的にインストールされ、信頼されるため、手動による信頼構成は不要になります。

# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust

この改善により、WSL を使用する場合の開発エクスペリエンスが合理化され、Windows 上の Linux 環境で作業する開発者にとって一般的な摩擦点が排除されます。

@StickFunさん、この貢献に感謝します！

ASP.NET Core におけるネイティブな OpenTelemetry のトレース

ASP.NET Core では、OpenTelemetry のセマンティック規則属性が、 OpenTelemetry HTTP サーバースパン仕様に合わせて HTTP サーバーアクティビティにネイティブに追加されるようになりました。既定では、必要なすべての属性が含まれており、以前は OpenTelemetry.Instrumentation.AspNetCore ライブラリでのみ使用できるメタデータと一致します。

組み込みのトレースデータを収集するには、OpenTelemetry 構成で Microsoft.AspNetCore アクティビティソースをサブスクライブします。

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("Microsoft.AspNetCore")
        .AddConsoleExporter());

追加のインストルメンテーションライブラリ ( OpenTelemetry.Instrumentation.AspNetCore など) は必要ありません。フレームワークは、 http.request.method、 url.path、 http.response.status_code、 server.addressなど、要求アクティビティのセマンティック規則属性を直接設定するようになりました。

アクティビティに OpenTelemetry 属性を追加しない場合は、 Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData AppContext スイッチを true に設定して無効にすることができます。

パフォーマンスの向上

Kestrel's HTTP/1.1 要求パーサーでは、不正な形式の要求を処理するために、スローしないコードパスが使用されるようになりました。パーサーは、解析エラーごとに BadHttpRequestException をスローするのではなく、成功、不完全、またはエラーの状態を示す結果構造体を返します。ポートスキャン、悪意のあるトラフィック、正しく構成されていないクライアントなど、形式が正しくない要求が多いシナリオでは、コストのかかる例外処理のオーバーヘッドが排除され、最大で 20 から 40%スループットが向上します。有効な要求処理に影響はありません。

HTTP ログミドルウェアは、 ResponseBufferingStream インスタンスをプールし、応答本文のログ記録またはインターセプターが有効になっている場合の要求ごとの割り当てを減らすようになりました。

重大な変更

.NET の破壊的変更に関する記事を使用して、アプリを新しいバージョンの .NET にアップグレードするときに適用される可能性のある破壊的変更を見つけます。

フィードバック

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

Last updated on 2026-03-11