InspectCode コマンドラインツール
JetBrains Rider の最も注目すべき機能の一つである コードインスペクションは、IDE を開かなくても利用できます。 無料のクロスプラットフォームコマンドラインツール InspectCode では、すべての JetBrains Rider のインスペクションを適用するために最低 1 つのパラメーター(ソリューションファイル)が必要です。
InspectCode を実行する
ReSharper コマンドラインツールをダウンロードします。 ダウンロードボタンの横にあるセレクタを使用して、オペレーティングシステムを選択します。
コマンドラインツールパッケージを任意のディレクトリに解凍します。
ダウンロードした .zip ファイルを展開する前に「ブロック解除」されていることを確認してください。ファイルを右クリックし、 プロパティ を選択して ブロック解除する をクリックします。 これを行わないと、.NET フレームワークがアプリケーションを部分信頼で読み込むため、正しく読み込まれず実行されません。
次のコマンドを実行します:
InspectCode.exe YourSolution.sln -o=<PathToOutputFile>または、 .NET ツールとしての ReSharper コマンドラインツールをインストールして、
jbコマンドで InspectCode を実行することもできます。
デフォルトの出力形式
InspectCode は分析を終了すると、結果を静的解析結果の交換形式 (SARIF) に保存します。 出力 .json ファイルは、コマンドプロンプト -o=<PathToOutputFile> で指定されます。 このファイルには、指定された範囲 (ソリューション全体または特定のプロジェクト) 内で見つかったすべてのコードの問題が含まれます。
出力をどのように処理するかはあなた次第です。 ただし、推奨される次のステップは、出力を HTML レポートに変換するか、検出された問題の数と種類に基づいて継続的インテグレーション (CI) サーバーでメッセージを生成することです。
代替出力フォーマット
InspectCode は、プレーンテキスト、XML、HTML など、他のフォーマットで出力ファイルを作成することもできます。 出力フォーマットを変更するには、コマンドラインに --format (-f) パラメーターを追加します。例えば:
XML 出力形式の構造
XML は次の 2 つの部分で構成されます。
各タイプが特定のインスペクションに対応し、次の属性を持つ見つかった問題タイプのリスト:
Id— 各問題を対応するインスペクションにリンクできます。Category— 同様の問題を カテゴリ別にグループ化するために使用できます。SubCategory— 一部の問題タイプが同じ SubCategory 属性を持っている場合、問題が同じですが、異なる言語または異なるスコープで見つかったことを意味します。 さらにグループ化するために使用できます。Description— 問題を説明しますSeverity— インスペクションの 重大度を示します。WikiUrl— 利用可能な場合は、対応する コードインスペクションインデックス エントリへのリンク。Global— ソリューション全体のコードインスペクションに通知します。
発見された問題のリストはプロジェクトごとにグループ化され、各問題には次の属性があります:
TypeId— 各問題を対応するインスペクションにリンクできます (レポートの最初の部分にIssueType)File— ソリューションに関連する、影響を受けるファイルへのパス。Offset— ファイルの先頭から問題のあるコードの先頭と末尾までのシンボルのオフセット範囲。Line- 問題のあるコードを含む行Message— 問題の簡単な説明。Severity— この属性は、問題の 重大度が対応するインスペクションの重大度と異なる場合にのみ表示されます。 これは、ソリューション内の一部プロジェクトで「警告をエラーとして扱う」オプションが有効化されており、他ではそうでない場合などに発生する可能性があります。この場合、一部の問題は「エラー」の重大度を持ち、元の「警告」の重大度とは異なります。
使用シナリオ
次に、このツールを使用する方法と、その出力で正確にできることを見てみましょう。 ローカルマシンで実行すると役立つ場合もありますが、JetBrains Rider がない場合に限ります。JetBrains Rider があれば、数回クリックで 選択したスコープのインスペクション結果を取得できます。
より有望なケースとしては、CI サーバー上で InspectCode を使用し、それをビルドスクリプトに統合して、コードインスペクションの結果をビルドレポートとメッセージに追加することが挙げられます。
JetBrains TeamCity は、InspectCode によって検出されたコードの問題を視覚的に表現した次のプレゼンテーションを作成しました。

詳細については、 TeamCity のドキュメント(英語)を参照するか、 最新バージョンの TeamCity をダウンロードして試してください。
分析前のソリューションの構築
デフォルトでは、InspectCode は分析を開始する前に NuGet パッケージを復元し、ターゲットソリューションをビルドします。 これにより、ツールは常に正しいソリューションモデルを持ち、関連するコードの問題のみを見つけることができます。
その旨の警告が出力に表示されますが、 --build または --no-build オプションを明示的に指定することで抑制できます。
多くの場合、デフォルトの挙動のままか、 --build オプションを使用することをおすすめします。InspectCode の実行前にすでにビルドステップが CI チェーンに含まれている場合でも、MSBuild は最近ビルドされたソリューションを非常に速く処理します。
それとは別に、正しい分析のために InspectCode によるビルドが必要なシナリオがあります。 例: ソリューションにソースジェネレーターがある場合、InspectCode は独自のロジックを使用して、生成されたファイルをディスクにダンプします。
ただし、不要なビルドによって不要なオーバーヘッドが発生する場合があります(たとえば、C++ プロジェクト)。 このような場合は、 --no-build オプションを使用して、InspectCode にビルドをスキップさせます。
DotSettings を使用して InspectCode を構成する
以前に JetBrains Rider を使ってターゲットソリューションに取り組んだことがある場合は、 コードインスペクション設定をすでに構成している可能性があります。 もしそうなら、InspectCode は .DotSettings ファイルの カスタム設定を検出し、適用します。 設定ファイルがない場合は、デフォルトの重要度レベルがすべてのインスペクションに使用されます。 コードインスペクションのカスタム重大度レベルのほかに、InspectCode は .DotSettings ファイルで次の設定を探します。
ソリューション全体の分析が有効かどうか (これは、 .DotSettings ファイルまたは
--swea/--no-sweaパラメーターのいずれかで構成できます。)命名ルール (これは .DotSettings ファイルでのみ設定できます)
コード分析から除外されたファイル、フォルダー、ファイルマスク。
--include/--excludeコマンドラインパラメーターを使用して、レポートに含めるファイルを指定することもできます。コード分析が部分的に無効になっている、生成コードを含むファイル、ファイルマスク、領域 (これは .DotSettings ファイルでのみ設定できます)
CI サーバーで InspectCode を構成する場合は、JetBrains Rider ですべての構成をローカルで行い、 ソリューションチーム共有レイヤーに設定を保存し、その結果得られた YourSolution.sln.DotSettings ファイルをソリューションディレクトリに VCS へコミットできます。 サーバー上の InspectCode は、これらの設定を見つけて適用します。
別の方法として、 --settings パラメーターを介して共有 .DotSettings ファイルへのパスを指定することができます(他の設定ファイルの設定がある場合はそれを上書きします)。
デフォルトでは、InspectCode はターゲットソリューション上で Roslyn アナライザーも実行します。 Roslyn アナライザーを無効にする場合は、次の 2 つの方法があります。
--propertiesパラメーターを使用する場合、例:InspectCode.exe YourSolution.sln -o=<PathToOutputFile> --properties=RunAnalyzers=falseソリューションの .DotSettings ファイルでは、例:
<wpf:ResourceDictionary xml:space="preserve" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:s="clr-namespace:System;assembly=mscorlib" xmlns:ss="urn:shemas-jetbrains-com:settings-storage-xaml" xmlns:wpf="http://schemas.microsoft.com/winfx/2006/xaml/presentation"> <!-- Enable/disable Roslyn analyzers and Source Generators --> <s:Boolean x:Key="/Default/CodeInspection/Roslyn/RoslynEnabled/@EntryValue">False</s:Boolean> <!-- Include/exclude Roslyn analyzers in Solution-Wide Analysis --> <s:Boolean x:Key="/Default/CodeInspection/Roslyn/UseRoslynInSwea/@EntryValue">False</s:Boolean> </wpf:ResourceDictionary>
EditorConfig を使用して、コードインスペクションを構成する
プロジェクトのコードスタイルを管理する ために EditorConfig を使用する場合は、 .editorconfig ファイルからコードインスペクションを設定することもできます。
EditorConfig の規則に従い、JetBrains Rider はカレントファイルのディレクトリおよびそのすべての親ディレクトリにある .editorconfig という名前のファイルで定義されたインスペクション設定を、ルートファイルパスに到達するか root=true を持つ EditorConfig ファイルが見つかるまで適用します。 .editorconfig ファイルで指定されているファイルマスク、たとえば *Test.cs も考慮されます。
.editorconfig ファイルのインスペクション設定は、他のプロパティと同様に、対応する行を追加して設定します:
例: 次の行を使用して、 可能性のある 'System.NullReferenceException' インスペクションの 重大度レベルを エラーに変更できます。
または、次の行で デフォルト値による冗長引数インスペクションを無効にすることができます。
各インスペクションの EditorConfig プロパティは、 コードインスペクションインデックス セクションと EditorConfig プロパティのインデックス ページのページにあります。 - ブラウザー検索を使用して目的のインスペクションのプロパティを探すだけです。
コマンドラインパラメーターで InspectCode を構成する
上記のいくつかのオプションパラメーターについてはすでに説明しました。 コマンドラインパラメーター(InspectCode.exe --help を入力してリストすることができます)の完全なリストを次に示します。
インスペクションパラメーター
--project— ソリューション全体ではなく、特定のプロジェクトを分析できます。 このパラメーターの後に、ソリューション内の複数のプロジェクトに一致するプロジェクト名またはワイルドカードを入力できます。 例:--project=*Billing。--include/--exclude— インスペクションレポートに含める / 除外するファイルを定義するファイルマスク。--includeと--excludeの両方が定義され、同じファイルセットをカバーする場合、--excludeが優先されます。ファイルマスクで Ant スタイルのワイルドカード(英語)を使用できます。
ディレクトリ区切り文字を除く単一文字に一致する
?ディレクトリ区切り文字を除く 0 文字以上に一致する
*ディレクトリ区切り文字を含む任意の数の文字に一致する
**OS パス形式に関係なくディレクトリ区切り文字と一致する
/または\
たとえば、パターン
**Test?\**.*は次のファイルと一致します。C:\Projects\MyTestX\data\file_one.txt
/home/projects/TestY/file_two.xml
だがしかし:
C:\Projects\Test\data\file_one.txt
/home/projects/TestY/file_two
複数のパスまたはワイルドカードを指定するには、セミコロン
;で区切るか、--include/--excludeパラメーターを複数回使用します。--sweaと--no-swea- これらのパラメーターは ソリューション全体の分析 を明示的に有効または無効にします。 それ以外の場合、ソリューション全体の分析は既存の設定に基づいて有効または無効になります。--severity (-e)— デフォルトでは、InspectCode は重要度レベル Suggestion以上の問題のみを報告します。 このパラメーターを使用すると、報告される最小の重大度レベルを[INFO, HINT, SUGGESTION, WARNING, ERROR]に変更できます。 例:-e=WARNING。--dumpIssuesTypes-it— このオプションを使用すると、すべての既存 コードインスペクションを 出力にダンプできます。 このオプションは、実際の解析とは別に、つまりソリューション引数なしで利用する必要があります。
MSBuild 関連のパラメーター
--build/--no-build— 分析を開始する前にターゲットソリューションを構築するかどうかを指定できます。 デフォルトでは、InspectCode は常にソリューションを構築します。--target— 分析を開始する前に実行する MSBuild ターゲットを指定できます。 ターゲットソリューションのすべての .csproj ファイルで定義する必要がある任意のターゲットを指定できます。 デフォルトでは、Buildターゲットが実行されます。ソリューションがビルドされていない場合、つまり
--no-buildパラメーターが指定されている場合、--targetパラメーターは適用されません。--properties— MSBuild のプロパティを上書きできます。 各プロパティを個別に設定するか(--properties:prop1=val1--properties:prop2=val2)、セミコロンを使用して複数のプロパティ--properties:prop1=val1;prop2=val2を区切ることができます。セミコロンは値の中で使用できないことに注意してください。例:
--properties:ReferencePath="r:\reference1\;r:\reference2\"。 このような場合は、それぞれの値を別々に別の--propertiesパラメーターで指定してください。値は結合されます。指定されたプロパティは、分析されたすべてのプロジェクトに適用されます。 現在、特定のプロジェクトのみにプロパティを設定する直接的な方法はありません。 回避策は、このプロジェクトでカスタムプロパティを作成し、それを目的のプロパティに割り当ててから、InspectCode パラメーターでカスタムプロパティを使用することです。
--toolset— このオプションを使うと、MSBuild バージョンを正確に指定できます。 例えば 12.0:--toolset=12.0デフォルトでは利用可能な中で最も高い MSBuild バージョンが使用されます。 同じバージョンのインストールが複数ある場合(例えば Visual Studio 2019 の 16.0 と .NET Core 3.x の 16.0 など)、このオプションが正しく動作しない可能性があります。--toolset-path— このオプションを使用して、MSBuild への正確なパスを指定します。 これは、カスタム MSBuild インストールがあり、それを InspectCode で使用する場合に役立ちます (例:--toolset-path="c:\tools\msbuild\bin\MsBuild.exe")。--dotnetcore— デフォルトでは、.NET インストールは自動検出されます。 自動検出で競合が発生した場合は、このオプションを使用して特定の .NET インストールを指定できます。 .NET Core を無視するには、引数なしで使用します。 例:--dotnetcore=/usr/local/share/dotnet/dotnet--dotnetcoresdk— このオプションを使用して、MSBuild を提供する .NET SDK バージョンを指定します。 例: .NET を SDK 5.0.100 および 6.0.302 とともにインストールした場合、InspectCode は 6.0.302 (プレビューバージョンを含む最新版) を優先します。 InspectCode を .NET SDK 5.0.100 とともに実行する場合は、コマンドラインに--dotnetcoresdk=5.0.100を追加します。--mono— デフォルトでは、Mono のインストールは自動検出されます。 自動検出によって競合が発生した場合は、このオプションを使用して、特定の Mono インストールを指すことができます。 Mono を無視するには、引数なしで使用してください。 例:--mono=/Library/Frameworks/Mono.framework/Versions/Current/bin/mono--targets-for-references— プロジェクトの参照アセンブリを取得するために実行されるカスタム MSBuild ターゲットの名前。 ターゲットは、プロジェクトファイルまたは .targets ファイルのいずれかで定義されます。 複数の値はセミコロンで区切られます。 例:--targets-for-references="GetReferences"。--targets-for-items— プロジェクトの他の項目 (たとえば、コンパイル項目) を取得するために実行されるカスタム MSBuild ターゲットの名前。 ターゲットは、プロジェクトファイルまたは .targets ファイルのいずれかで定義されます。 複数の値はセミコロンで区切られます。 例:--targets-for-items="GetCompileItems"。
補助パラメーター
--output-o— 出力ファイルを設定できます。--format (-f)— デフォルトでは、InspectCode は出力を SARIF 形式で書き込みます。 必要に応じて、このパラメーターを使用して他の出力形式[Html, Text, Xml]を指定できます。 例:-f=Text。一度の実行で複数の出力成果物を生成するには、希望するフォーマットをセミコロンで区切って指定してください(例:
--format=Html;Xml)、またはこのパラメーターを複数回追加します(例:--format=Html --format=Xml)。 複数の成果物を生成する場合、--outputパラメーターでディレクトリを指定するとファイル名が自動生成されます。または、ファイル名を指定すると異なる成果物ごとに異なるファイル拡張機能が使用されます。--jobs (-j)— デフォルトでは、InspectCode はヒューリスティックを使用してジョブを分割し、使用可能な数のスレッド / コアを使用してジョブを並列に実行します。 必要に応じて、-j=4などのスレッド数を制限できます。--absolute-paths (-a)— デフォルトでは、InspectCode のレポート内のファイルは、ソリューションファイルに相対的なパスで書き込まれます。 このスイッチを使用して、レポートに絶対パスを含めることができます。--debug (-d)— このオプションを使用して、InspectCode の実行の詳細を出力に追加します。 InspectCode に問題がある場合は、 サポートチーム(英語)に連絡するときにこれらの詳細が役立ちます。--verbosity— デフォルトでは、InspectCode は出力にエラーメッセージのみを表示します。 このパラメーターを使用して、出力に書き込まれる情報の量を次のレベルで変更します (順序は少ないものから詳細なものへ):[OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE]--LogLevel— このパラメーターを使用して、--LogFileまたは--LogFolderで指定された、ログファイルに書き込まれる情報の量を制御します。 次のレベルがあります (順序は少ないものから詳細なものへ):[OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE].例えば、InspectCode で問題が発生した場合は、JetBrains Rider サポートに連絡して、すべての TRACE メッセージを含むログファイルを共有できます:
--LogLevel=TRACE。--LogFile— このパラメーターを使用して、InspectCode からのメッセージのログファイルへの絶対パスを指定します。 MSBuild および Roslyn からのログも必要な場合は、代わりに--LogFolderパラメーターを使用します。--LogFolder— このパラメーターを使用して、InspectCode からのログと MSBuild および Roslyn からのログを書き込むディレクトリへの絶対パスを指定します。 InspectCode からのログのみが必要な場合は、代わりに--LogFileパラメーターを使用します。--caches-home— InspectCode がキャッシングするデータのカスタム保存場所を指定できます。 デフォルトでは %LOCALAPPDATA% ディレクトリが使われますが、設定ファイルがある場合はそちらの指定が優先されます。 このパラメーターは、高速 SSD をキャッシング用に使いたい場合や、ビルド処理データを一箇所に保存したい場合などに便利です。--config-createと--config— これらのオプションで、上記のパラメーターを構成ファイル経由で渡すことができます。 最初のオプションは現在のパラメーターに基づいて構成ファイルを作成し、2 つ目のオプションはそのファイルからパラメーターを読み込みます。--eXtensions (-x)— 指定されたプラグインをインストールして有効にします。プラグインはその ID で指定します。ID は JetBrains Marketplace のプラグインページで、目的のプラグインを探して 概要 タブの一番下までスクロールすることで確認できます。
例: JetBrains による StyleCop(英語) プラグインのプラグイン ID は
StyleCop.StyleCopであり、このプラグインで InspectCode を実行するには、コマンドラインに-x=StyleCop.StyleCopを追加する必要があります。複数のプラグインを指定するには、それらの ID をセミコロンで区切ります。
--source— プラグインをインストールするためのカスタムパッケージソース、つまり .nupkg ファイルがあるディレクトリ(例:--source="C:\plugins")を指定できます。 何も指定しない場合、InspectCode は JetBrains Marketplace でプラグインを探します。--measure— 特定のハードウェアやターゲットソリューションでツールを実行した際にパフォーマンスが充分でない場合に役立つ診断オプションです。 このオプションは次のいずれかの引数[sampling | timeline (Windows-only) | memory]と組み合わせて使い、プロファイリングの種類を定義します。例:InspectCode.exe YourSolution.sln -o=<PathToOutputFile>実行が完了すると、問題レポートファイルに加えて、InspectCode によって実行スナップショットが作成され、スナップショットファイルへのパスが表示されます。 JetBrains ツールを使用してスナップショットを調べることができます。
サンプリングまたは タイムラインプロファイリング: 結果の .zip ファイルを分析するには、それを解凍し、サンプリングスナップショットファイル ( .dtp ) またはタイムラインスナップショットファイル ( .dtt ) を JetBrains dotTrace で開きます。
メモリプロファイリング: 結果の dotMemory ワークスペースファイル ( .dmw ) を分析するには、 JetBrains dotMemory で開きます。
--version (-v)— このオプションを使用して、ツールの現在のバージョンを表示して終了します。--no-updates— デフォルトでは、InspectCode は実行ごとに更新をチェックします。 更新のチェックを無効にするには、このオプションを使用します。
ReSharper 設定を制御するパラメーター
--settings— デフォルトでは、存在する場合は InspectCode が 『ソリューション チーム共有』レイヤー SolutionName.DotSettings の ReSharper 設定でデフォルト設定をオーバーライドします。 必要に応じて、このパラメーターを使用して、他のすべての設定をオーバーライドする別の .DotSettings ファイルを指定できます。 たとえば、--settings="C:\Work\MyRsSettings.DotSettings"。
--disable-settings-layers (-dsl)— 指定された 設定レイヤーを無効にします。 許容値:GlobalAll、GlobalPerProduct、SolutionShared、SolutionPersonal--no-buildin-settings— グローバル、ソリューション、プロジェクト設定レイヤーからの設定を抑制します。--disable-settings-layers: GlobalAll; GlobalPerProduct; SolutionShared; SolutionPersonal; ProjectShared; ProjectPersonalと同等
以下に、いくつかのコマンドラインオプションを指定して InspectCode を実行する例を示します。
MSBuild。 考えられる問題と解決策
InspectCode がターゲットソリューションファイルを受け取ると、インスペクションするファイルのリストを作成し、言語バージョンなどの多くのプロパティを初期化する必要があります。 InspectCode は MSBuild を使用して、プロジェクトファイルからこの情報を取得します。
ほとんどの場合、InspectCode はターゲットソリューションに適した MSBuild 実行可能ファイルを自動的に検出します。 ただし、ソリューションランタイムのバージョンがインストールされている .NET SDK のバージョンと一致しない場合など、自動検出を妨げる問題がある可能性があります。
InspectCode で The current .NET SDK does not support targeting .NET Core 3.0. や The SDK 'Microsoft.NET.Sdk' specified could not be found. などのエラーが発生した場合は、追加の パラメーターを使用して正しい SDK またはランタイムを指定する必要があります。 .NET を使用する場合は、MSBuild がすでにマシンにインストールされており、複数のインストールが存在することが多いため、ターゲットソリューションに適合するものを提供する必要があります。
ほとんどの場合、追加が必要なのは --toolset または --dotnetcore のいずれか 1 つのパラメーターです。 複雑なケース、例えばマシン上にさまざまなインストールがある場合や MSBuild のカスタムバージョンを使用している場合には、他のパラメーター --toolset-path、 --mono、 --targets-for-references、 --targets-for-items が必要になる場合もあります。
--dotnetcore または --dotnetcoresdk を指定すると、InspectCode は .NET SDK の MSBuild を使用し、その他は無視します。 例: マシンに MSBuild、v 16.0 が複数インストールされていて、 --dotnetcore を使用して .NET インストールへのパスを指定すると、InspectCode は指定されたインストールから .NET MSBuild を使用します。 --dotnetcore が指定されていない場合、InspectCode はソリューションディレクトリを調べて global.json を見つけ、そこに指定されている SDK バージョンを使用します。 何も見つからない場合は、利用可能な最新の SDK バージョンが使用されます。
プロジェクト参照。 考えられる問題と解決策
MSBuild は InspectCode によっても、参照プロジェクトやアセンブリからシンボルを解決するために使用されます。 環境に応じて異なる参照を使用するためのプロジェクトプロパティが 2 つあります: Platform と Configuration。 InspectCode を実行する環境がプロジェクトを最後にビルドした環境と異なる場合、 Can't resolve reference XXX: Reference wasn't resolved by MsBuild や Could not resolve this reference. Could not locate the assembly "XXX" などのエラーが発生することがあります。
このようなエラーが発生した場合は、出力を確認して、ビルド構成に不一致があるかどうかを確認してください。 たとえば
上記では、プロジェクトファイルで指定されたプラットフォームが x86 であることがわかりますが、ツールは 64 ビットモードで実行されています。 これを修正するには、 --properties パラメーター --properties:Platform=x64;Configuration=Debug を使用してターゲットプラットフォームと構成を明示的に指定します。
サポートされている言語とテクノロジー
InspectCode は、次の言語とテクノロジーのコードの問題を検出します。