dotnet-inspect について
dotnet-inspectは、.NETのAPI、ライブラリ、パッケージ、依存関係の根拠を調べる開発者向けコマンドラインスキルです。検索と詳細調査、バージョン比較、ポータブルなWorkspace定義の作成・編集に対応します。
主な機能
- 01APIとパッケージの検索
- 02型、メンバー、ライブラリの調査
- 03APIと実装の変更比較
- 04バージョン間のAPI履歴追跡
- 05ポータブルなWorkspaceの作成と編集
活用シーン
- 01プラットフォームライブラリから.NET APIを探す
- 02パッケージの依存関係とライセンス文書を調べる
- 03パッケージのバージョン間で破壊的変更を比較する
- 04リリース間でのAPI変更を追跡する
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ richlander/ dotnet-inspect --skill dotnet-inspectインストール後、Claude Code で/dotnet-inspectを入力して読み込まれたか確認します。
詳細
dotnet-inspect
dotnet-inspect を使用すると、直接参照できるローカルライブラリ、構成済みソースのパッケージ、Platform ライブラリから、API や依存関係を含む証拠を見つけられます。
dnx dotnet-inspect -y -- <command-or-target> を実行します。-y は確認をスキップし、-- は残りの引数を dotnet-inspect に渡します。まず、必要な結果の種類を特定します。意図や結果の範囲が不明確な場合は、対象だけを指定してルーターに選択させます。それ以外の場合は、該当する検索領域を直接指定します。Platform クエリでは、要求されたバージョンが利用可能であればインストール済みのパックを使用し、利用できない場合はパッケージベースのソースを使用します。標準的でないインストールの場合は、<root>/packs を確認し、PATH ではなくプロセススコープの DOTNET_ROOT を設定してください。
よくある開始方法
| 目的 | コマンド |
|---|---|
| インストール済みの機能を見つける | タスクは分かっているものの、コマンド、キー、セクションが分からない場合は、explain <task-text> を実行してインストール済みの機能を類似検索します。たとえば、explain literal を実行し、結果の Explain パスを explain <path> .hal --json にコピーしてから、次のように本番環境のバインディングに従います:package query Microsoft.Azure.SignalR --where "library-literal=https://" --tfm net8.0 --json。ルートがすでに分かっている場合は、-D または -Q を直接使用します。 |
| パッケージを見つける、または調べる | package query Foo で完全一致するパッケージ ID を検索します。パッケージ ID のリテラルな接頭辞で検索するには、package query 'Foo.*' を使用します。次に、既知のパッケージを調べるには package <exact-id> を使用します。 |
| API シンボルを見つける | スコープを明示しない場合、find はインストール済みの .NET Runtime、ASP.NET Core、.NET Standard の各プラットフォーム集団を検索します。これには、フレームワーク集団に含まれる Microsoft.Extensions アセンブリも含まれます。find JsonSerializer -n 5 --table、find ControllerBase -n 5 --table、または find OptionsBuilder -n 5 --table を試してください。パッケージ API は、明示的な --package Foo@version、復元済みの --project path/to/project、または型/メンバーのパターンと組み合わせた --package-prefix PREFIX によってスコープに追加されます:find IChatClient --package Microsoft.Extensions.AI.Abstractions -n 5 --table は Microsoft.Extensions.AI.IChatClient を返します。パッケージ ID の検索には package query Pattern を使用し、メンバー名を含めるには --members を追加します。明示的な Package または Platform の検索では、--tfm を指定すると、Find の Markdown、ヒント、テーブル、ルート配列の JSON、正確な実装アセット、互換性のある TFM が維持されます。 |
| 型を調べる | type Type --package Foo を使用します。非公開/非表示のメンバーも含めるには --all を追加します。-k では論理的な宣言種別を選択します。明示的なプロパティ/イベントには property/event を指定し、explicit-interface-implementation は合成されていない明示的なメソッドを選択します。作成者のソースを優先し、明示的なフォールバックコンテキストを含めるには -S Source を選択します。PDB Source と Decompiled Source は、引き続きプロバイダー固有のビューです。 |
| オーバーロードを調べる | member Type --platform Lib -m Name -S "Member Index" |
| オーバーロードを選択する | member Type --platform Lib Name:1 または Name~digest |
| 1 つのメンバーに関する Findings を関連付ける | member Type Method:1 --package Foo -S "Finding Census" --json は、1 つのレシートにスコープされた Facts と注釈付きソースのエンベロープを返します。選択方法とフォーマットの制約については、skill query を読み込んでください。 |
| 有効なクエリ値やデモを見つける | explain vocabularies --json でインストール済みのボキャブラリーを一覧表示します。返されたパスを explain <path> .hal --json にコピーし、埋め込み値と関連するボキャブラリーを確認してください。製品ホームのシナリオには demo list を使用します。 |
| クエリのファセットと演算子を見つける | library -Q でクエリ可能なセクションを一覧表示します。type -Q "Body Shapes" または library -Q "Performance: Arrays" --json で、調査を実行せずに使用可能なキーと演算子を確認できます。 |
| レンダリングされた本文の構文を見つける | library path/to.dll --where "Kind=ObjectCreationExpression"、type Type --library path/to.dll --where "Kind=InvocationExpression"、または member Type Method:1 --library path/to.dll --where "Kind=InvocationExpression" を使用します。安定した種別と座標については、skill decompiler を読み込んでください。 |
| API やメソッド本文を比較する | diff --package [email protected] --breaking を使用します(新しい API には --additive、割り当ての回帰には --alloc-regressions、正確な Implementation Diff セクションには --implementation を指定します)。単一ライブラリの API Diff は、投影されていない完全な Content を --json で、完全なサービス値を --envelope でサポートします。Share は現在、投影できません。1 つの API 座標について、完全な対応結果と診断が必要な場合は、type または member ... --match --envelope を使用します。順序付きの一致エンドポイントも投影できません。match Type.MethodA Type.MethodB --package Foo --body は、構造的な結果に C#/IL の本文の差分を追加します。match Type.Method --similar --package Foo は、検索用に構造的な候補を順位付けします。 |
| API の変遷を追跡する | diff --history --package [email protected] --type Type --members --at all を使用します。全集団を評価する場合は --at を省略し、明示的なチェックポイントを指定する場合は繰り返し指定します。適応的な二分探索には --max-probes を使用し、決定論的な集団相対サーベイには任意の --max-probes 上限とともに --sample-percent P を追加するか、メジャーバージョンごとに代表を 1 つ選ぶには --major-versions を使用します。メジャーバージョン単位の API 履歴では、最初の安定版を使用し、プレビュー版のみのメジャーでは最新のプレリリース版を代わりに使用します。Analysis 履歴では、メジャーバージョンごとに最新の採用済みバージョンを使用します。 |
| パッケージとエコシステムを調べる | package Foo で既知の完全一致パッケージ ID を調べます。正確なバージョンを確認するには package Foo --version 1.2.3、一覧の最新バージョン行を取得するには package Foo --versions -n 1、最新バージョンを新たに確認するには package Foo@latest --versions を使用します。セクションを見つけるには -D、同梱されたライセンス文書を一覧表示するには -S Licenses、テキストを含むファイルと SourceLink マッピングを監査するには -S "Signals,Audit: Findings" を使用します。package activity --ecosystem aspire は、指定したエコシステムの正確なパッケージセットを過去 42 日間にわたってスキャンします。--security-only、UTC の正確な --from/--through タイムスタンプのペア、または完全な Content の --json を追加できます。完全なサービス値には --envelope を使用します。カスタム/認証済みソースについては、skill private-feeds を読み込んでください。 |
| パッケージをクエリする | package query Foo は、条件を満たす一覧済みバージョンのうち最新のものを選択します。パッケージ ID のリテラルな接頭辞には 'Foo.*' を使用します。nuspec のライセンス値として有効なのは any、MIT、OSMF です。アーカイブを開かずに済ませるには、これらを --where および --nuspec-only とともに使用します。見つかったファセットの演算子と関係を調べてから --where と組み合わせるには、explain <facet-path> を使用します。Product プランナーは --tfm から library-target を作成します。メタデータの取得にコストがかかるクエリで候補として認められるのは最大 5 件です。最終的な Results には、型付きの選択済みライブラリコンテキスト、正確な Root の再オープン、完全な出現箇所が保持されます。-n と --rows はパッケージの Results を選択するものであり、出現箇所を選択するものではありません。--envelope は完全な package-query Content と診断を保持しますが、Package Query Share は現在、投影できません。 |
| Workspace を作成またはインベントリ化する | workspace --register-ecosystem runtime は、取得を行わずに移植可能なパケットを出力します。アクティベーション URL には --share url を追加し、パケットの JSON には --json を使用します。workspace --packet "$w" は、コンテンツを実体化せずにパケットを検証して再出力します。すべてのコンテキストにわたる網羅的なライブインベントリには --inventory を追加します。--kind、-n、--rows、--count で型付きエントリを絞り込みます。対象を調べるには、許可された --workspace "$w" コンテキストを指定して、通常の package、library、type、member コマンドを使用します。package Foo --workspace "$w" は、派生した Workspace 内で許可済みの Package を再利用するか、追加してアクティベートできます。dotnet-inspect -w "$w" または生のパケット入力で適用します:Workspace はインベントリを表示し、保存済みの Package Libraries は通常の階層を表示します。その他の保存済みファセット/クエリは、明示的に失敗します。 |
| 移植可能な Workspace を編集する | workspace component list --packet "$w" を使用して、正規パスを取得します。次に、workspace package add PACKAGE@VERSION --packet "$w"、workspace package update packages/ID@VERSION/TFM/RID --packet "$w" --version NEW、または workspace package remove packages/ID@VERSION/TFM/RID --packet "$w" を使用します。編集すると、既定で新しいパケットが出力されます。対応している場合、add と update ではコンテキストまたは TFM を選択でき、update では --json --envelope を出力できます。パケットを変換するには workspace packet encode または workspace packet decode を使用します。 |
| ライブラリを見つける、または調べる | library Foo または library path/to.dll で既知のソースを調べます。Library 単位の検索には、library query ./bin --where "references=System.Text.Json" または library query --platform runtime ... を使用します。セクションを見つけるには -D、構造形式の機能を追加するには -D --details、ライブラリ全体の構造レポートには -S "Library Metrics"、単独の unsafe の証拠には -S "Unsafe Members" を使用します。正確な Library の --count は public Type 宣言を数え、type Type --library path/to.dll --count は Members を数えます。ECMA-335 の生テーブル/ヒープについては、skill metadata を読み込んでください。 |
| 依存関係と関連性 | パッケージグラフと宣言の証拠には depends --package Foo@version --tfm net10.0 を使用します。証拠のみを取得するには -S Dependencies を追加し、パッケージ候補をインストール済みのプラットフォームインベントリと比較するには -S Pruning を明示的に選択します。外部に焦点を当てたメンバーグラフを作成し、ルートパッケージの依存関係を自動的にたどるには graph calls TYPE MEMBER --root-package Foo@version --root-tfm net10.0 を使用します。既定のベースラインではサードパーティの Package 境界が強調されます。この焦点を変更するには --baseline self または --baseline nothing を使用します。正確なペアワイズ呼び出し使用クラスターには graph libraries --library ./Consumer.dll --library ./Provider.dll -S "Direct Use Clusters" を使用します。型の関連性を調べるには、depends Type、extensions Type、type Interface -S Implementers、または type Base -S "Derived Types" を使用します。位置引数の depends Type は、完全な Content を --json で、または完全なサービス値を --envelope でサポートします。アセットモードはエンベロープをサポートしません。スコープと意味については、skill relationships を読み込んでください。 |
メンバーの検索
スコープが不明な場合は find Name を実行して型を確認し、その後 -S "Member Index" でオーバーロードを一覧表示します。Name:N(1始まり)または Name~digest(安定)で選択します。選択したオーバーロードの既定値は Signature です。完全修飾名 Namespace.Type.Member にはスコープは不要です。
ヒント
packageとlibraryは、簡潔でトークン効率が高く、価値の高いドメインコンテンツを既定で生成します。出力は Markdown、表、TSV、JSONL、JSON に対応しています。選択、エンベロープ、共有 URL、投影、制限についてはdotnet-inspect skill queryを読み込んでください。検出された語彙、クエリ空間、クエリファセットのパスには、explain <path> .hal --jsonを使用します。HAL はナビゲーションに_links、含まれるデータに_embeddedを使用します。リンクを取得する前に埋め込みデータを確認し、出力された href は変更せずにexplain "$href" --jsonでたどり、jq でフィルタリングする際はdata_scopeを保持してください。- プロジェクトで参照されるパッケージを対象に含める場合は、
--project <csproj|dir|project.assets.json>を追加します。既存の復元済みアセットを読み取るため、依存関係を変更した場合は先に restore/build を実行してください。 workspace --inventoryは、コミット済みの Packages を、非アクティブな Exact Library、Package Prefix、Ecosystem の登録より先に報告します。JSON/JSONL では、型付きのエントリーアームが保持されます。これは既存の Workspace コンテンツを一覧表示するものであり、Find はその許可された母集団から一致する項目を検索します。通常の Workspace 出力は移植可能な定義であり、入れ子になったworkspace component、workspace package、workspace ecosystem、workspace prefixコマンドが、コンポーネントの確認と不変の編集を担います。- 一般的な BCL 型はスコープなしで解決できます:
type string、type 'List<T>'。ジェネリックとパターンは引用符で囲みます:member 'Dictionary<TKey,TValue>'、-S "Async*"。バージョン固定されていないパッケージは最新の安定版を使用します。プレリリース API には--previewを追加してください。
固定テキストの解釈
[Text omitted: required containment]:テキストに懸念事項があったため、完全な値またはドキュメントは共有されませんでした。これは悪意があったことを意味するものではありません。REDACTED:URL クエリまたは認証情報を含むパスセグメントが削除されました。<unparsable-url>:オーソリティのような値を URL コンポーネントに解析できなかったため、元のロケーターは表示されませんでした。<absent>または(absent):要求されたパッケージドキュメントは存在しませんでした。これは封じ込めや墨消しを意味するものではありません。\u202E、\U0001F600、\^[などのバックスラッシュ形式は、ソーステキストを可逆な視覚表記として保持します。これらは置換ではありません。表示または保存の前に、実際の制御文字や書式文字へデコードしないでください。