次の方法で共有

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

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またはNavLinkを使用してを設定します。

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

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

Blazor Hybrid

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

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

SignalR

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

最小限の API

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

OpenAPI

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

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

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

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

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

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

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

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

認証と承認

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

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機能の決定論的なテストをより簡単に作成できます。

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さん、この貢献に感謝します！

  • Last updated on