.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 startup」を参照してください。

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

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

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

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

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

`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 Web Worker テンプレート (`blazorwebworker`)

Blazor WebAssembly アプリはクライアントで重いコンピューティングを実行できますが、UI スレッドで実行すると UI のレンダリングが妨げられるため、ユーザーエクスペリエンスに悪影響を及ぼします。 .NET 10 では、UI スレッドから Web Worker への負荷の高い作業のオフロードを容易にするために、サンプルアプリを含む記事を追加しました。 .NET 11 では、Blazor Web Worker プロジェクトテンプレート (blazorwebworker) が追加されました。このテンプレートは、Blazor WebAssembly アプリで Web Worker で.NET コードを実行するためのインフラストラクチャを提供します。詳細については、.NET を使用して Web Worker 上で稼働する ASP.NET CoreBlazor を参照してください。

`Virtualize` 実行時に高さ可変項目に適応

Virtualize<TItem> コンポーネントでは、すべての項目の高さが同じとは見なされなくなりました。コンポーネントは実行時に測定された項目サイズに適応するようになりました。これにより、項目の高さが異なる場合に間違った間隔とスクロールが減少します。これらの更新には、Virtualize<TItem>.OverscanCount の既定値への更新が含まれます。これは、.NET 10 以前では 3 であり、.NET 11 以降では 15 に変更されます。既定値の変更により、アイテムの平均高さの計算の精度が向上します。

詳細については、Item size および Overscan count のセクションASP.NET Core Razor コンポーネントの仮想化を参照してください。

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さん、この貢献をありがとうございます！

認証と承認

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

ASP.NET Core における `TimeProvider` のサポート 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 セマンティック規則属性が HTTP サーバーアクティビティにネイティブに追加されるようになりました。これは、OpenTelemetry 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 の HTTP/1.1 要求パーサーでは、不正な形式の要求を処理するために、スローしないコードパスが使用されるようになりました。パーサーは、解析エラーごとに BadHttpRequestException をスローするのではなく、成功、不完全、またはエラーの状態を示す結果構造体を返します。ポートスキャン、悪意のあるトラフィック、正しく構成されていないクライアントなど、形式が正しくない要求が多いシナリオでは、コストのかかる例外処理のオーバーヘッドが排除され、最大で 20 から 40%スループットが向上します。有効な要求処理に影響はありません。

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

Zstandard リクエストの展開と応答の圧縮

ASP.NET Coreでは、応答の圧縮と要求の展開の両方で Zstandard (zstd) がサポートされるようになりました。これにより、既存の応答圧縮ミドルウェアと要求展開ミドルウェアに zstd のサポートが追加され、既定で zstd が有効になります。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions
    {
        Quality = 6 // 1-22, higher = better compression, slower
    };
});

この貢献を@manandreに感謝いたします。ありがとうございます。

HTTP/3 が以前に要求の処理を開始する

Kestrel 制御ストリームと SETTINGS フレームを先に待機せずに HTTP/3 要求の処理を開始します。これにより、新しい接続での最初の要求の待機時間が短縮されます。

重大な変更

Breaking changes in .NETの記事を使用して、アプリを新しいバージョンの.NETにアップグレードする際に該当する可能性のある破壊的変更を見つけましょう。

フィードバック

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

Last updated on 2026-04-15