デバッグ

Visual Studio Code で C# アプリケーションをデバッグするには、Microsoft C# 拡張機能を使用します。

実行とデバッグ

C# 拡張機能は、C# Dev Kit とともに、C# アプリケーションを実行およびデバッグするための複数の方法を提供します。

C# Dev Kit なしで実行およびデバッグする方法については、ドキュメントとしてMicrosoft C# 拡張機能の GitHub ページを参照してください。

F5 でデバッグ

C# Dev Kit 拡張機能がインストールされており、デバッグビューで選択できるデバッグ構成がない場合、.cs ファイルを開いてF5キーを押すことでプロジェクトのデバッグを開始できます。デバッガーは自動的にプロジェクトを見つけ、デバッグを開始します。複数のプロジェクトがある場合は、どのプロジェクトのデバッグを開始するかを尋ねられます。

VS Code のサイドバーにある実行とデバッグビューからデバッグセッションを開始することもできます。VS Code でのデバッグで詳細を参照してください。

ソリューションエクスプローラーでデバッグ

C# Dev Kit 拡張機能がインストールされている場合、ソリューションエクスプローラーでプロジェクトを右クリックすると、デバッグコンテキストメニューが表示されます。

3 つのオプションがあります。

• 新しいインスタンスを開始 - デバッガーをアタッチしてプロジェクトを開始します。
• デバッグなしで開始 - デバッガーをアタッチせずにプロジェクトを実行します。
• 新しいインスタンスにステップイン - デバッガーをアタッチしてプロジェクトを開始しますが、コードのエントリーポイントで停止します。

コマンドパレットでデバッグ

C# Dev Kit 拡張機能がインストールされている場合、デバッグ: デバッグを選択して開始コマンドを使用して、コマンドパレット⇧⌘P (Windows, Linux Ctrl+Shift+P)からもデバッグを開始できます。

注: これにより、デバッグドロップダウンリストに起動構成エントリが追加されます。

動的 (インメモリ) 起動構成でデバッグ

C# Dev Kit 拡張機能がインストールされている場合、動的な起動構成を作成できます。作成方法は、プロジェクトに既存の launch.json ファイルがあるかどうかによって異なります。

既存の launch.json

既存の launch.json がある場合、デバッグビューに移動し、ドロップダウンを選択して C# オプションを選択できます。これにより、ドロップダウンリストに追加できる起動ターゲットの選択肢が表示されます。選択後、F5を押すか、新しく生成された構成でデバッグを開始できます。

launch.json がない場合

プロジェクトに launch.json がない場合、デバッグビューのすべての自動デバッグ構成を表示でこれらの動的構成を追加およびアクセスできます。

動的 (インメモリ) 起動構成の削除

生成された構成は、コマンドパレット⇧⌘P (Windows, Linux Ctrl+Shift+P)とデバッグ: デバッグを選択して開始コマンドを使用して削除できます。

ドロップダウンには、既存のすべてのデバッグ構成が一覧表示されます。動的構成の上にカーソルを合わせると、右側にクリック可能なゴミ箱アイコンが表示されます。そのアイコンを選択して動的構成を削除できます。

エディターのデバッグ/実行ボタンでデバッグ

エディターで .cs ファイルが開かれている場合、エディターウィンドウの右上隅にあるボタンから実行およびデバッグオプションにアクセスできます。これらのアクションは、現在のファイルを使用してプロジェクトシステムを照会し、起動する関連プロジェクトを決定します。

2 つのオプションがあります。

• このファイルに関連付けられたプロジェクトを実行: これは、デバッグアダプターを使用して noDebug: true でプログラムを起動します。
• このファイルに関連付けられたプロジェクトをデバッグ: これは、デバッガーの下でプログラムを起動します。

launch.json でデバッグ

C# Dev Kit を使用している場合、このオプションを使用しないことをお勧めします。ただし、デバッグ構成を直接変更する必要がある場合は、C# デバッグのための launch.json の構成を参照してください。

プロセスへのアタッチ

コマンドパレット⇧⌘P (Windows, Linux Ctrl+Shift+P)を使用し、デバッグ: .NET 5+ または .NET Core プロセスにアタッチコマンドを実行することで、C# プロセスにアタッチできます。

構成オプション

デバッガーを構成するための多くのオプションと設定が利用可能です。launchSettings.json、VS Code のユーザー設定を使用してデバッグオプションを変更するか、直接 launch.json を変更することができます。

launchSettings.json

Visual Studio から launchSettings.json がある場合、F5 から実行またはコマンドパレットから実行を使用してプロファイルが一覧表示されます。

詳細については、C# デバッグの構成を参照してください。

ユーザー設定

C# デバッガーを使用中に変更したい設定がある場合は、ファイル > ユーザー設定 > 設定 (⌘, (Windows, Linux Ctrl+,)) でこれらのオプションを検索してください。

• csharp.debug.stopAtEntry - true の場合、デバッガーはターゲットのエントリポイントで停止します。このオプションの既定値は false です。
• csharp.debug.console - コンソールプロジェクトを起動する際、ターゲットプログラムを起動するコンソールを示します。注: このオプションは「dotnet」デバッグ構成タイプでのみ使用されます。
  • internalConsole [既定] - VS Code のデバッグコンソール。このモードでは、デバッガーとターゲットプログラムの両方からのメッセージを 1 か所で確認できます。詳細については、完全なドキュメントを参照してください。
  • integratedTerminal - VS Code の統合ターミナル。
  • externalTerminal - ユーザー設定で構成できる外部ターミナル。
• csharp.debug.sourceFileMap - ビルド時のパスをローカルソースの場所にマップします。ビルド時のパスのすべてのインスタンスは、ローカルソースパスに置き換えられます。
    例
      {\"<ビルドパス>\":\"<ローカルソースパス>\"}
• csharp.debug.justMyCode - 有効な場合 (既定)、デバッガーはユーザーコード ("マイコード") のみを表示してステップインし、システムコードや最適化されたコード、デバッグシンボルを持たない他のコードを無視して、より高速な評価を試みます。詳細情報。
• csharp.debug.requireExactSource - 現在のソースコードが pdb と一致することを要求するフラグ。このオプションの既定値は true です。
• csharp.debug.enableStepFiltering - プロパティと演算子をスキップするステップ実行を有効にするフラグ。このオプションの既定値は true です。
• csharp.debug.logging.exceptions - 例外メッセージをアウトプットウィンドウにログ記録するかどうかを決定するフラグ。このオプションの既定値は true です。
• csharp.debug.logging.moduleLoad - モジュールロードイベントをアウトプットウィンドウにログ記録するかどうかを決定するフラグ。このオプションの既定値は true です。
• csharp.debug.logging.programOutput - 外部コンソールを使用しない場合、プログラム出力をアウトプットウィンドウにログ記録するかどうかを決定するフラグ。このオプションの既定値は true です。
• csharp.debug.logging.diagnosticsLog - デバッガーの問題を診断するために使用されるさまざまな設定。
• csharp.debug.logging.browserStdOut - Webブラウザ起動時の標準出力テキストをアウトプットウィンドウにログ記録するかどうかを決定するフラグ。このオプションの既定値は true です。
• csharp.debug.logging.elapsedTiming - trueの場合、エンジンログには、リクエストにかかった時間（マイクロ秒単位）を示すadapterElapsedTimeとengineElapsedTimeプロパティが含まれます。このオプションの既定値はfalseです。
• csharp.debug.logging.threadExit - ターゲットプロセス内のスレッドが終了したときにメッセージをログに記録するかどうかを制御します。このオプションの既定値はfalseです。
• csharp.debug.logging.processExit - ターゲットプロセスが終了したとき、またはデバッグが停止したときにメッセージがログに記録されるかどうかを制御します。このオプションの既定値はtrueです。
• csharp.debug.suppressJITOptimizations - trueの場合、最適化されたモジュール（リリース構成でコンパイルされた.dll）がターゲットプロセスにロードされると、デバッガーはJust-In-Timeコンパイラに最適化を無効にしたコードを生成するように要求します。詳細情報
• csharp.debug.symbolOptions.searchPaths - .pdb ファイルを検索するシンボルサーバーの URL (例: http://MyExampleSymbolServer) またはディレクトリ (例: /build/symbols) の配列。これらのディレクトリは、モジュールの隣の既定の場所と、PDB が最初にドロップされたパスに加えて検索されます。
• csharp.debug.symbolOptions.searchMicrosoftSymbolServer - true の場合、Microsoft Symbol server (https://msdl.microsoft.com/download/symbols) がシンボル検索パスに追加されます。指定されていない場合、このオプションは false が既定値です。
• csharp.debug.symbolOptions.searchNuGetOrgSymbolServer - true の場合、NuGet.org シンボルサーバー (https://symbols.nuget.org/download/symbols) がシンボル検索パスに追加されます。指定されていない場合、このオプションは false が既定値です。
• csharp.debug.symbolOptions.cachePath - シンボルサーバーからダウンロードしたシンボルをキャッシュするディレクトリ。指定されていない場合、Windows ではデバッガーは %TEMP%\\SymbolCache を既定とし、Linux および macOS ではデバッガーは ~/.dotnet/symbolcache を既定とします。
• csharp.debug.symbolOptions.moduleFilter.mode - モジュールフィルターが動作する 2 つの基本的な動作モードのどちらを制御します。
  • loadAllButExcluded - モジュールが excludedModules 配列に含まれていない限り、すべてのモジュールのシンボルをロードします。
  • loadOnlyIncluded - includedModules 配列に含まれているか、includeSymbolsNextToModules 設定で含まれている場合を除き、どのモジュールについてもシンボルをロードしようとしません。
• csharp.debug.symbolOptions.moduleFilter.excludedModules - デバッガーがシンボルをロードすべきでないモジュールの配列。ワイルドカード (例: MyCompany.*.dll) がサポートされます。このプロパティは、mode が loadAllButExcluded に設定されていない限り無視されます。
• csharp.debug.symbolOptions.moduleFilter.includedModules - デバッガーがシンボルをロードすべきモジュールの配列。ワイルドカード (例: MyCompany.*.dll) がサポートされます。このプロパティは、mode が loadOnlyIncluded に設定されていない限り無視されます。
• csharp.debug.symbolOptions.moduleFilter.includeSymbolsNextToModules - trueの場合、includedModules配列に含まれていないモジュールについては、デバッガーはモジュール自体の隣と起動実行可能ファイルの隣をチェックしますが、シンボル検索リスト上のパスはチェックしません。このオプションの既定値はtrueです。このプロパティは、modeがloadOnlyIncludedに設定されていない限り無視されます。
• csharp.debug.allowFastEvaluate - true (デフォルトの状態) の場合、デバッガーは単純なプロパティやメソッドの実行をシミュレートすることで、より高速な評価を試みます。
• csharp.experimental.debug.hotReload - trueの場合、ターゲットアプリケーションがホットリロードをサポートしていれば、デバッガーはデバッグ中に変更の適用を有効にします。
• csharp.debug.hotReloadOnSave - true (既定の状態) の場合、ファイルを保存するとデバッガーは自動的にコード変更を適用します。
• csharp.debug.hotReloadVerbosity - C# ホットリロード出力ウィンドウのログの詳細度を制御します。minimal (既定)、detailed、または diagnostic に設定できます。ホットリロードが予期せぬ動作を開始した場合、詳細度レベルを上げることをお勧めします。

Breakpoints

C# デバッガーは、ソース行ブレークポイント、条件付きブレークポイント、ログポイントなど、さまざまなブレークポイントをサポートしています。

ブレークポイント - 条件付きブレークポイント

式評価の助けを借りて、デバッガーは条件付きブレークポイントもサポートしています。式が true と評価されたときにブレークポイントを停止するように設定できます。

ブレークポイント - 関数ブレークポイント

デバッガーは機能ブレークポイントもサポートしています。デバッグペインのブレークポイントセクションにある+をクリックすることで、特定の関数でブレークポイントを設定できます。

ブレークポイント - ログポイント

ログポイント（Visual Studio ではトレースポイントとも呼ばれます）を使用すると、コードを編集することなくデバッグコンソールに出力を送信できます。これらは、アプリケーションの実行フローを停止しないため、ブレークポイントとは異なります。

ログポイントを追加するには、コード行のすぐ左側の余白を右クリックします。「ログポイントを追加」を選択し、ログに記録したいメッセージを入力します。波括弧 ('{' と '}') で囲まれた式は、ログポイントに到達したときに評価されます。

以下のトークンもログメッセージでサポートされています。

ブレークポイント - トリガーされたブレークポイント

トリガーされたブレークポイントとは、別のブレークポイントに到達すると自動的に有効になるブレークポイントです。これらは、特定の事前条件の後にのみ発生するコードの失敗ケースを診断する際に非常に役立ちます。

トリガーされたブレークポイントは、グリフマージンを右クリックし、トリガーされたブレークポイントの追加を選択し、その後、どの他のブレークポイントがこのブレークポイントを有効にするかを選択することで設定できます。

例外発生時の停止

C# デバッガーは、例外がスローまたはキャッチされたときにデバッガーが停止するタイミングに関する構成オプションをサポートしています。これは、実行ビューのブレークポイントセクションにある 2 つのエントリを介して行われます。

注：ブレークポイントセクションは、そのフォルダーがC#デバッガーで初めてデバッグされるまで、これらのエントリを欠落させます。

すべての例外をチェックすると、例外がスローされたときにデバッガーが停止するように構成されます。Just My Codeが有効になっている場合（デフォルトで有効）、デバッガーはライブラリコード内で内部的にスローされ、キャッチされた例外では中断しません。ただし、例外がライブラリコードでスローされ、ユーザーコードに返された場合、デバッガーは中断します。

ユーザー未処理例外をチェックすると、ユーザーコードでスローされた後、またはユーザーコードを経由した後、非ユーザーコードでキャッチされた場合にデバッガーが停止するように構成されます。ユーザー未処理になった例外が、必ずしもデバッグ中のプロセスのバグであるとは限りません。ユーザーコードがAPIを実装しており、例外を発生させることが期待されている場合もあります。多くの場合、実際の問題があるため、デフォルトでは、例外がユーザー未処理になったときにデバッガーは停止します。

例外条件

両方のチェックボックスは、選択した例外タイプのみでブレークする条件をサポートしています。条件を編集するには、鉛筆アイコンを選択するか（上記の画像を参照）、エントリを右クリックして条件を編集を呼び出します。条件は、ブレークする例外タイプのコンマ区切りリスト、またはリストが「!」で始まる場合は、無視する例外タイプのリストです。

条件の例

Expression evaluation

デバッガーでは、ウォッチウィンドウとデバッグコンソールの両方で式を評価できます。

ホットリロード

C# Dev Kit 拡張機能がインストールされている場合、デバッガーはデバッグ中に C# コードの変更を適用できます。

ホットリロードを有効にするには、csharp.experimental.debug.hotReload を true に設定する必要があります。ユーザー設定で詳細を参照してください。ホットリロードセッションは、ターゲットデバッガーエンジンがコード変更の適用をサポートしている場合にのみ開始されます。

サポートされているプロジェクトとシナリオ

C# Dev Kitは、「Edit and Continue」としても知られる「クラシック」ホットリロードエクスペリエンスをサポートしています。ブレークポイントで停止しているか、プログラムが実行されているかに関わらず、デバッグ中にコードの変更を適用できます。

2023年11月現在、ASP.NET Core アプリケーションが変更後にブラウザを自動的に更新できるようにするMetadataUpdateHandlerなどの一部の機能はまだ利用できません。デバッグなしでのコード変更の適用もサポートされていません。

.NET 8 で Linux/macOS でのデバッグ中の変更適用がランタイムに追加されたため、これらのオペレーティングシステムで実行されている .NET アプリのコード変更を適用するには、.NET 8 以降のランタイムバージョンが必要です。

C# Dev Kit が現在サポートしているプロジェクトの詳細については、サポートされているプロジェクトを参照してください。また、その他のサポートされていないシナリオのトラブルシューティングについては、C# Dev Kit FAQも参照してください。

コード変更の適用方法

ホットリロードセッションが開始され、新しい変更が行われたら、以下のいずれかのアクションでこれらの変更をアプリケーションに適用できます。

次のステップ

さらに読む

• デバッグ - あらゆる言語のプロジェクトで VS Code のデバッガーを使用する方法を確認してください。