タグ: aspnetcore

ASP.NET Core 11 で UseSwaggerUI を MapScalarApiReference に置き換えます。ルーティング、複数ドキュメント、認証情報の事前入力、本番環境での制御、CDN 不要のアセット、そして Scalar 固有の OpenAPI 拡張を解説します。

両者は選択肢の関係にありません。WebApplicationFactory はアプリケーションを起動し、Testcontainers はその依存先を起動します。.NET SDK 10.0.201 で計測した結果、コンテナーを持つフィクスチャはクラスあたり 1.7 秒、SQLite なら 10 ミリ秒。そして Postgres が 22001 で拒否する HasMaxLength(16) 違反を、SQLite は黙って受け入れます。

再接続モーダルはアプリがクラッシュしたのではなく、SignalR の circuit が切れたという合図です。再試行が failed で終わるか rejected で終わるかを確認し、セッションアフィニティ、3 分の保持期間、32 KB 制限を直すか、[PersistentState] で状態を保存してください。

.NET 11 の内部サービス間呼び出しでは、契約の両端を自分たちで所有していて呼び出しがポイントツーポイントであれば、既定で gRPC を選んでください。自分たちが管理していないものがそのサービスを呼び出す必要が出た時点で、JSON を使う REST に切り替えます。SignalR はサービス間の RPC トランスポートではありません。1 つの生産者が多数の長寿命な消費者へメッセージを配信する必要がある場合にのみ使ってください。

500.30 は、アプリが w3wp.exe の中で起動中に例外をスローしたという意味です。実際の例外は Windows のアプリケーション イベント ログに IIS AspNetCore Module V2 として既に記録されています。まずそれを読み、次に原因を順に絞り込みます。共有フレームワークの未インストール、アプリケーション プールの x86/x64 不一致、構成の欠落、プールの権限です。

IValidateOptions<T> を実装し、DI に登録して ValidateOnStart をチェーンすれば、不正な appsettings.json は最初にそれに触れたリクエストではなくプロセスそのものを落とします。.NET 11 の Validate<TValidator>() オーバーロード、IAsyncValidateOptions<T> による非同期検証、そして ValidateOnStart が黙って何もしない 3 つのケースを解説します。

ASP.NET Core 11 で Kestrel の HTTP/3 を有効にするための完全ガイドです。HttpProtocols.Http1AndHttp2AndHttp3 によるエンドポイント設定、Windows / Linux / macOS における MsQuic のプラットフォーム要件、最初のリクエストが決して HTTP/3 にならない理由、HttpClient とミドルウェアによる確認方法、QuicTransportOptions のチューニング、そして黙ってフォールバックさせてしまうファイアウォールとプロキシの落とし穴を扱います。

既定では IOptions<T> を使ってください。シングルトンが設定のリロードを見る必要がある場合は IOptionsMonitor<T> を、スコープ付きの利用側が 1 リクエストの間だけ安定した値を必要とする場合にのみ IOptionsSnapshot<T> を選びます。判断軸は設定の形ではなく、利用側のライフタイムです。

プリレンダリングはブラウザーのないサーバー上でコンポーネントを実行するため、IJSRuntime が例外を投げます。呼び出しを OnAfterRenderAsync に移すか、RendererInfo.IsInteractive で分岐するか、プリレンダリングを無効にしてください。

既存の ASP.NET Core ソリューションに Aspire 13.4 を追加します。新しいプロジェクト 2 つとサービスあたり 3 行だけで済ませる手順として、aspire init、AddProject と WithReference による AppHost の配線、既存の launchSettings.json と接続文字列の維持、そして初日にぶつかる resilience、ヘルスエンドポイント、プロキシの落とし穴を解説します。