タグ: dotnet-11

PGO（プロファイルに基づく最適化）は、.NET の JIT がワークロードで実際に通る型や分岐に合わせてホットなコードを特化させる仕組みです。Dynamic PGO は .NET 8 以降デフォルトで有効なので、.NET 8 以降では有効化する必要はありません。PGO が何をするのか、その効果をどう確認するのか、そして設定に手を入れる数少ないケースを解説します。

階層型コンパイルは、.NET の JIT に各メソッドを2回コンパイルさせます。まずアプリを起動させるために高速かつ未最適化で、次にランタイムがメソッドをホットだと認識した時点で完全な最適化を施して再度コンパイルします。本記事では tier 0、tier 1、オンスタック置換、Dynamic PGO がどう組み合わさるか、そしてそれらをどう観測し調整するかを解説します。

dotnet build は内側の開発ループのためにプロジェクトをコンパイルし、既定で Debug を使います。dotnet publish は MSBuild の Publish ターゲットを実行し、net8.0 以降では既定で Release を使い、Web アセット、自己完結型ランタイム、単一ファイル、トリミング、AOT まで処理済みのデプロイ可能なフォルダーをパッケージ化します。ここではそれぞれが何を生成し、いつ使うかを正確に説明します。

dotnet run はプロジェクトを一度ビルドして起動します。dotnet watch は dotnet run をファイル監視で包み、ソースファイルを保存するたびにアプリを再起動するか hot reload を適用します。それぞれが正確に何をするのか、dotnet watch が設定して dotnet run が設定しないものは何か、どちらをいつ使うのかを解説します。

ASP.NET Core 11 の minimal API ハンドラーにある手書きの if チェックを、DataAnnotations とソースジェネレーターに基づく組み込みバリデーターへ置き換えるためのステップバイステップの移行ガイドです。何が壊れるか、どの手動ルールが移植できてどれができないか、そして 400 ProblemDetails の契約が同一のままであることをどう検証するかを扱います。

トリムセーフなコードとは、.NET トリマーが静的に到達可能だと証明できるコードのことで、自己完結型アプリから未使用コードが削除されても生き残ります。本記事は実践ガイドです。アナライザーを有効にし、すべての IL2xxx 警告をゼロにし、リフレクションを DynamicallyAccessedMembers で注釈し、RequiresUnreferencedCode を公開 API まで伝播させ、解析不能なパターンをソースジェネレーターに置き換えます。

リクエストの Content-Type がエンドポイントのバインド対象と一致しないと、minimal API は 415 を返します。ボディにバインドする型には Content-Type: application/json を送信し、フォームやファイルアップロードには [FromForm] を使ってください。

CS9035 は required とマークされたメンバーが割り当てられていないことを意味します。オブジェクト初期化子で割り当てるか、すべての required メンバーを設定する [SetsRequiredMembers] 付きのコンストラクターを追加します。

AddProblemDetails に CustomizeProblemDetails コールバックを渡して、ASP.NET Core 11 の組み込み Minimal API バリデーションが返す 400 の形を作り直します。traceId を追加したり、title を書き換えたり、400 を 422 に切り替えたり、カスタム IProblemDetailsWriter で完全に制御したりできます。

ASP.NET Core 11 の minimal API における JWT bearer 認証の完全で動作する設定です。パッケージのインストール、AddAuthentication().AddJwtBearer() の配線、トークンの発行、RequireAuthorization によるエンドポイントの保護、ロールと claim のポリシーの追加、そして dotnet user-jwts によるテストまでを扱います。