VS Codeのエージェントモードを拡張するには、を試してください！

C# デバッグの構成

Visual Studio Code で C# デバッガーを構成するには、launch.json、launchSettings.json、またはユーザーの settings.json ファイルを使用できます。

チュートリアル: コマンドライン引数の設定

すべての可能なオプションの詳細に入る前に、基本的なシナリオ、つまりプログラムにコマンドライン引数を設定する手順を見ていきましょう。これらの手順は、環境変数や現在の作業ディレクトリなどの他の基本的なオプションを更新する場合にも機能します。

アプローチ 1: launchSettings.json

C# Dev Kit の場合、デバッグの推奨される方法は、プロジェクトファイルの設定から C# Dev Kit がデバッグ方法を自動的に判断するようにすることです。これは、<workspace_root>/.vscode/launch.json ファイルがないか、ある場合はアクティブな構成に "type": "dotnet" が設定されていることを意味します。コマンドライン引数については、「プロジェクトファイルから判断する」とは、<Project-Directory>/Properties/launchSettings.json から値を取得することを意味します。launchSettings.json の利点は、Visual Studio Code、完全な Visual Studio、および dotnet run の間で設定を共有できることです。

この場合、コマンドライン引数を設定する手順は次のとおりです。

  1. ワークスペースエクスプローラービューで、起動したいプロジェクト (.csproj ファイル) のディレクトリに移動します
  2. Properties ディレクトリがまだない場合は、作成します
  3. launchSettings.json ファイルがまだない場合は、作成してください。以下のテキストを例として使用できます
  4. commandLineArgs プロパティを、使用したいコマンドライン引数に変更します

launchSettings.json ファイルの例:

{
  "profiles": {
    "MyLaunchProfileName": {
      "commandName": "Project",
      "commandLineArgs": "MyFirstArgument MySecondArgument"
    }
  }
}

アプローチ 2: launch.json

VS Code で coreclr または clr デバッグアダプタータイプを使用している場合、コマンドライン引数は <workspace_root>/.vscode/launch.json に保存されます。この場合、それらを編集するには

  1. <workspace_root>/.vscode/launch.json を開きます
  2. 起動したい coreclr または clr 起動構成を見つけます
  3. args プロパティを編集します。これは文字列でも、文字列の配列でもかまいません

launchSettings.json の構成

C# Dev Kit を使用すると、Visual Studio から launchSettings.json を Visual Studio Code で動作させることができます

例

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "https://:59481",
      "sslPort": 44308
    }
  },
  "profiles": {
    "EnvironmentsSample": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://:7152;https://:5105",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "EnvironmentsSample-Staging": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://:7152;https://:5105",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Staging",
        "ASPNETCORE_DETAILEDERRORS": "1",
        "ASPNETCORE_SHUTDOWNTIMEOUTSECONDS": "3"
      }
    },
    "EnvironmentsSample-Production": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://:7152;https://:5105",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Production"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

プロファイルプロパティ

  • commandLineArgs - 実行中のターゲットに渡す引数。
  • executablePath - 実行可能ファイルへの絶対パスまたは相対パス。
  • workingDirectory - コマンドの作業ディレクトリを設定します。
  • launchBrowser - ブラウザーを起動する場合は true に設定します。
  • applicationUrl - Web サーバー用に構成する URL のセミコロン区切りリスト。
  • sslPort - Web サイトに使用する SSL ポート。
  • httpPort - Web サイトに使用する HTTP ポート。

構成可能なオプションの一覧

以下は、デバッグ中に変更したい一般的なオプションです。

PreLaunchTask

preLaunchTask フィールドは、プログラムをデバッグする前に tasks.json 内の関連するタスク名を実行します。VS Code コマンドパレットから **Tasks: Configure Tasks Runner** コマンドを実行することで、デフォルトのビルドプリランチタスクを取得できます。

これにより、dotnet build を実行するタスクが作成されます。詳細については、VS Code のタスクドキュメントを参照してください。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ❌

プログラム

プログラムフィールドには、起動するアプリケーションの DLL または .NET Core ホスト実行可能ファイルのパスが設定されます。

このプロパティは通常、"${workspaceFolder}/bin/Debug/<target-framework>/<project-name.dll>" の形式をとります。

例: "${workspaceFolder}/bin/Debug/netcoreapp1.1/MyProject.dll"

ここで

  • <target-framework> は、デバッグ対象のプロジェクトがビルドされるフレームワークです。これは通常、プロジェクトファイルで 'TargetFramework' プロパティとして見つかります。
  • <project-name.dll> は、デバッグ対象プロジェクトのビルド出力 DLL の名前です。これは通常、プロジェクトファイル名と同じですが、'.dll' 拡張子が付きます。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (executablePath として)

Cwd

ターゲットプロセスの作業ディレクトリ。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (workingDirectory として)

引数

これらはプログラムに渡される引数です。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (commandLineArgs として)

エントリで停止

ターゲットのエントリポイントで停止する必要がある場合は、オプションで stopAtEntry を "true" に設定できます。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.stopAtEntry として)
  • launchSettings.json ❌

Web ブラウザーの起動

ASP.NET Core プロジェクトのデフォルトの launch.json テンプレート (C# 拡張機能 v1.20.0 時点) は、ASP.NET 起動時に VS Code が Web ブラウザーを起動するように、次のように構成します

    "serverReadyAction": {
        "action": "openExternally",
        "pattern": "\\bNow listening on:\\s+(https?://\\S+)"
    }

これに関する注意事項

  1. ブラウザーを自動的に起動したくない場合は、この要素を削除するだけです (launch.json に代わりに launchBrowser 要素がある場合はそれも)。

  2. このパターンは、ASP.NET Core がコンソールに書き込む URL を使用して Web ブラウザーを起動します。URL を変更したい場合は、「ブラウザーの URL を指定する」を参照してください。これは、ターゲットアプリケーションが別のマシンやコンテナーで実行されている場合、または applicationUrl に特別なホスト名 (例: "applicationUrl": "http://*:1234/") がある場合に役立つことがあります。

  3. serverReadyAction は VS Code の新機能です。C# 拡張機能がリモートマシンで実行されている場合でも動作し、VS Code 用に構成されたデフォルトのブラウザーを使用し、スクリプトデバッガーの使用も可能であるため、C# 拡張機能のデバッガーに組み込まれている以前の launchBrowser 機能よりも推奨されます。これらの機能のいずれも重要でない場合は、代わりに launchBrowser を使い続けることができます。デフォルトのブラウザーを起動する代わりに特定のプログラムを実行したい場合も、launchBrowser を使い続けることができます。

  4. serverReadyAction の詳細なドキュメントは、Visual Studio Code 2019 年 2 月のリリースノートで確認できます。

  5. これは、VS Code がコンソールに出力された内容をスクレイピングすることで動作します。行がパターンに一致した場合、そのパターンによって「キャプチャ」された URL に対してブラウザーを起動します。

    パターンが何をするかの説明です

    • \\b : 単語の境界に一致します。\b は単語の境界を示しますが、これは JSON 文字列であるため、\ はエスケープする必要があり、したがって \\b となります。
    • Now listening on: : これは文字列リテラルであり、次のテキストが Now listening on: でなければならないことを意味します。
    • \\s+ : 1つ以上の空白文字に一致します。
    • ( : これは「キャプチャグループ」の開始です。これは、ブラウザーを起動するために保存および使用されるテキストの領域を示します。
    • http : 文字列リテラル。
    • s? : 文字 s または何もなし。
    • :// : 文字列リテラル。
    • \\S+ : 1つ以上の非空白文字。
    • ) : キャプチャグループの終了。

  6. ブラウザー起動の両方の形式では "console": "internalConsole" が必要です。これは、Web サーバーが初期化されたことを知るために、ブラウザーランチャーがターゲットプロセスの標準出力をスクレイピングするためです。

ブラウザーの URL を指定する

コンソール出力からの URL を無視したい場合は、パターンから ( と ) を削除し、uriFormat を起動したいものに設定できます。

例

    "serverReadyAction": {
        "action": "openExternally",
        "pattern": "\\bNow listening on:\\s+https?://\\S",
        "uriFormat": "https://:1234"
    }

コンソール出力からのポート番号は使用したいが、ホスト名ではない場合は、次のようなものも使用できます。

    "serverReadyAction": {
        "action": "openExternally",
        "pattern": "\\bNow listening on:\\s+http://\\S+:([0-9]+)",
        "uriFormat": "https://:%s"
    }

実際、ほぼすべての URL を開くことができます。例えば、次のようにすることでデフォルトの Swagger UI を開くことができます

    "serverReadyAction": {
        "action": "openExternally",
        "pattern": "\\bNow listening on:\\s+http://\\S+:([0-9]+)",
        "uriFormat": "https://:%s/swagger/index.html"
    }

注意 これを行うには、プロジェクトに Swagger UI がセットアップされていることを確認する必要があります。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (launchBrowser と applicationUrl を使用)

環境変数

環境変数は、このスキーマを使用してプログラムに渡すことができます

    "env": {
        "myVariableName":"theValueGoesHere"
    }

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (environmentVariables として)

コンソール (ターミナル) ウィンドウ

"console" 設定は、ターゲットアプリが起動されるコンソール (ターミナル) ウィンドウを制御します。次のいずれかの値に設定できます --

  • "internalConsole" (デフォルト) : ターゲットプロセスのコンソール入力 (stdin) と出力 (stdout/stderr) は、VS Code デバッグコンソールを介してルーティングされます。このモードの利点は、デバッガーとターゲットプログラムの両方からのメッセージを1か所で確認できるため、重要なメッセージを見逃したり、頻繁に切り替えたりする必要がないことです。これは、単純なコンソール操作を行うプログラム (例: Console.WriteLine および/または Console.ReadLine の使用) に役立ちます。カーソル位置を変更するプログラム、入力に Console.ReadKey を使用するプログラムなど、ターゲットプログラムがコンソールを完全に制御する必要がある場合には、これを使用しないでください。コンソールへの入力方法については以下を参照してください。
  • "integratedTerminal" : ターゲットプロセスは、VS Code の統合ターミナル内で実行されます。アプリケーションと対話するには、エディターの下にあるタブグループのターミナルタブを選択します。このモードを使用する場合、デフォルトでは、デバッグ開始時にデバッグコンソールは表示されません。launch.json を使用している場合、これは internalConsoleOptions で構成できます。
  • "externalTerminal": ターゲットプロセスは、独自の外部ターミナル内で実行されます。このモードを使用する場合、Visual Studio Code と外部ターミナルウィンドウの間でフォーカスを切り替える必要があります。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.console として)
  • launchSettings.json ❌

注意: csharp.debug.console 設定は、dotnet デバッグ構成タイプで起動されたコンソールプロジェクトにのみ使用されます。

internalConsole 使用時のターゲットプロセスへのテキスト入力

internalConsole を使用する場合、Console.ReadLine や stdin から読み取る類似の API から返されるテキストを Visual Studio Code に入力できます。そのためには、プログラムの実行中に、デバッグコンソール下部の入力ボックスにテキストを入力します。Enter キーを押すと、テキストがターゲットプロセスに送信されます。プログラムがデバッガーで停止しているときにこのボックスにテキストを入力した場合、このテキストは C# 式として評価され、ターゲットプロセスには送信されないことに注意してください。

例

Example of inputting text to the Console to be set to the target process's standard input

launchSettingsProfile と launchSettingsFilePath

launchSettings.json の完全なサポートには、"type": "dotnet" を持つ起動構成の使用が必要ですが、coreclr および clr デバッガータイプも launchSettings.json 機能の限定されたサブセットをサポートしています。これは、Visual Studio Code と完全な Visual Studio の両方で同じ設定を使用したいユーザーにとって便利です。

使用する (または使用しないようにする) launchSettings.json プロファイルを構成するには、launchSettingsProfile オプションを設定します

    "launchSettingsProfile": "ProfileNameGoesHere"

これにより、例えば、この例の launchSettings.json ファイルから myVariableName が使用されます

{
  "profiles": {
    "ProfileNameGoesHere": {
      "commandName": "Project",
      "environmentVariables": {
        "myVariableName": "theValueGoesHere"
      }
    }
  }
}

launchSettingsProfile が指定されていない場合、"commandName": "Project" を持つ最初のプロファイルが使用されます。

launchSettingsProfile が null または空文字列に設定されている場合、Properties/launchSettings.json は無視されます。

デフォルトでは、デバッガーは {cwd}/Properties/launchSettings.json で launchSettings.json を検索します。このパスをカスタマイズするには、launchSettingsFilePath を設定します

   "launchSettingsFilePath": "${workspaceFolder}/<Relative-Path-To-Project-Directory/Properties/launchSettings.json"

制限事項

  1. "commandName": "Project" を持つプロファイルのみがサポートされます。
  2. environmentVariables、applicationUrl、および commandLineArgs プロパティのみがサポートされます
  3. launch.json の設定は launchSettings.json の設定よりも優先されます。したがって、例えば launch.json で args が既に空文字列/配列以外のものに設定されている場合、launchSettings.json の内容は無視されます。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ❌

ソースファイルマップ

この形式でマップを提供することにより、ソースファイルがどのように開かれるかをオプションで構成できます

    "sourceFileMap": {
        "C:\\foo":"/home/me/foo"
    }

この例では

  • C:\foo は、モジュール (例: MyCode.dll) がコンパイルされたときの1つ以上のソースファイル (例: program.cs) の元の場所です。ソースファイルがその下にあるディレクトリでも、ソースファイルへの完全なパス (例: c:\foo\program.cs) でもかまいません。Visual Studio Code を実行しているコンピューター上、またはリモートデバッグしている場合はリモートマシン上に存在する必要はありません。デバッガーは .pdb (シンボル) ファイルからソースファイルへのパスを読み取り、このマップを使用してパスを変換します。
  • /home/me/foo は、Visual Studio Code が現在ソースファイルを見つけることができるパスです。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.sourceFileMap として)
  • launchSettings.json ❌

マイ コードのみ

justMyCode を "false" に設定してオプションで無効にできます。シンボルがない、または最適化されているダウンロードしたライブラリをデバッグしようとしている場合は、「マイ コードのみ」を無効にする必要があります。

    "justMyCode":false

「マイ コードのみ」は、使用している最適化されたライブラリ (.NET Framework 自体など) の詳細の一部を非表示にすることで、コードのデバッグに集中しやすくする一連の機能です。この機能の最も重要なサブパートは次のとおりです --

  • ユーザー未処理の例外: フレームワークによって例外がキャッチされる直前にデバッガーを自動的に停止します
  • マイ コードのみのステップ実行: ステップ実行中に、フレームワークコードがユーザーコードにコールバックする場合、自動的に停止します。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.justMyCode として)
  • launchSettings.json ❌

正確なソースを要求

デバッガーは PDB とソースコードが完全に同じであることを要求します。これを変更し、ソースが同じである必要を無効にするには、次を追加します

    "requireExactSource": false

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.requireExactSource として)
  • launchSettings.json ❌

プロパティと演算子へのステップイン

デバッガーはデフォルトでマネージドコードのプロパティと演算子をスキップします。ほとんどの場合、これによりより良いデバッグエクスペリエンスが提供されます。これを変更し、プロパティまたは演算子へのステップインを有効にするには、次を追加します

    "enableStepFiltering": false

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.enableStepFiltering として)
  • launchSettings.json ❌

ログ記録

出力ウィンドウにログを記録するメッセージをオプションで有効または無効にできます。ログフィールドのフラグは、「exceptions」、「moduleLoad」、「programOutput」、「browserStdOut」、「consoleUsageMessage」です。

デバッガーの問題を診断することを目的とした、「logging.diagnosticsLog」の下に高度なオプションもあります。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.logging の下)
  • launchSettings.json ❌

パイプトランスポート

デバッガーが別の実行可能ファイルを使用して VS Code と .NET Core デバッガーバックエンド (vsdbg) の間で標準入出力を中継し、リモートコンピューターに接続する必要がある場合は、このスキーマに従って pipeTransport フィールドを追加します

    "pipeTransport": {
        "pipeProgram": "ssh",
        "pipeArgs": [ "-T", "ExampleAccount@ExampleTargetComputer" ],
        "debuggerPath": "~/vsdbg/vsdbg",
        "pipeCwd": "${workspaceFolder}",
        "quoteArgs": true
    }

パイプトランスポートに関する詳細情報は、こちらで確認できます。

Windows Subsystem for Linux (WSL) のパイプトランスポート構成に関する情報は、こちらで確認できます。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ❌

オペレーティングシステム固有の構成

オペレーティングシステムごとに変更する必要がある特定のコマンドがある場合は、「windows」、「osx」、「linux」のフィールドを使用できます。特定のオペレーティングシステムのために、上記のフィールドのいずれかを置き換えることができます。

JIT 最適化の抑制

.NET デバッガーは次のオプションをサポートしています。true の場合、最適化されたモジュール (リリース構成でコンパイルされた .dll) がターゲットプロセスにロードされると、デバッガーは Just-In-Time コンパイラに最適化が無効化されたコードを生成するように要求します。このオプションのデフォルトは false です。

    "suppressJITOptimizations": true

.NET における最適化の仕組み: コードをデバッグしようとする場合、そのコードが最適化されていない方が簡単です。これは、コードが最適化されると、コンパイラとランタイムが生成される CPU コードに変更を加えて実行を高速化しますが、元のソースコードとの直接的なマッピングが少なくなるためです。これにより、デバッガーはローカル変数の値を頻繁に伝えられなくなり、コードのステップ実行やブレークポイントが期待どおりに機能しない可能性があります。

通常、リリースビルド構成は最適化されたコードを作成し、デバッグビルド構成は最適化されたコードを作成しません。Optimize MSBuild プロパティは、コンパイラにコードを最適化するように指示するかどうかを制御します。

.NET エコシステムでは、コードはソースから CPU 命令に2段階のプロセスで変換されます。まず、C# コンパイラが入力したテキストを MSIL と呼ばれる中間バイナリ形式に変換し、これを .dll ファイルに出力します。次に、.NET ランタイムがこの MSIL を CPU 命令に変換します。どちらのステップも多少の最適化を行うことができますが、.NET ランタイムが実行する2番目のステップがより重要な最適化を行います。

オプションの機能: このオプションは、最適化が有効な状態でコンパイルされた DLL がターゲットプロセス内にロードされたときに何が起こるかを制御します。このオプションが false (デフォルト値) の場合、.NET ランタイムが MSIL コードを CPU コードにコンパイルするときに、最適化は有効のままになります。このオプションが true の場合、デバッガーは最適化を無効にするように要求します。

このオプションを使用すべき場合: このオプションは、NuGet パッケージなどの別のソースから DLL をダウンロードし、この DLL 内のコードをデバッグしたい場合に使用すべきです。これが機能するためには、この DLL のシンボル (.pdb) ファイルも見つける必要があります。

ローカルでビルドしているコードのみをデバッグしたい場合は、このオプションを false のままにしておくのが最善です。なぜなら、場合によっては、このオプションを有効にするとデバッグが著しく遅くなるためです。この遅延には2つの理由があります --

  • 最適化されたコードはより速く実行されます。多くのコードの最適化をオフにすると、時間が加算される可能性があります。
  • 「マイ コードのみ」を有効にしている場合、デバッガーは最適化された DLL のシンボルをロードしようとさえしません。シンボルを見つけるには長い時間がかかることがあります。

このオプションの制限: このオプションが機能しない状況が2つあります

1: 既に実行中のプロセスにデバッガーをアタッチしている状況では、このオプションはデバッガーがアタッチされた時点で既にロードされていたモジュールには影響しません。

2: このオプションは、ネイティブコードにプリコンパイル (ngen'd) された DLL には影響しません。ただし、環境変数 COMPlus_ReadyToRun を 0 に設定してプロセスを開始することで、プリコンパイルされたコードの使用を無効にできます。.NET Core の古いバージョン (2.x) をターゲットにしている場合は、COMPlus_ZapDisable も '1' に設定してください。デバッガーで起動している場合、この構成は launch.json にこの設定を追加することで設定できます

    "env": {
        "COMPlus_ZapDisable": "1",
        "COMPlus_ReadyToRun": "0"
    }

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.suppressJITOptimizations として)
  • launchSettings.json ❌

シンボルオプション

symbolOptions 要素は、デバッガーがシンボルを検索する方法をカスタマイズできます。例:

    "symbolOptions": {
        "searchPaths": [
            "~/src/MyOtherProject/bin/debug",
            "https://my-companies-symbols-server"
        ],
        "searchMicrosoftSymbolServer": true,
        "searchNuGetOrgSymbolServer": true,
        "cachePath": "/symcache",
        "moduleFilter": {
            "mode": "loadAllButExcluded",
            "excludedModules": [ "DoNotLookForThisOne*.dll" ]
        }
    }

プロパティ

searchPaths: .pdb ファイルを検索するためのシンボルサーバー URL (例: https://msdl.microsoft.com/download/symbols) またはディレクトリ (例: /build/symbols) の配列。これらのディレクトリは、デフォルトの場所、モジュールの隣、および .pdb が元々配置されたパスに加えて検索されます。

searchMicrosoftSymbolServer: true の場合、Microsoft シンボルサーバー (https://msdl.microsoft.com/download/symbols) がシンボル検索パスに追加されます。指定されていない場合、このオプションのデフォルトは false です。

searchNuGetOrgSymbolServer: true の場合、Nuget.org シンボルサーバー (https://symbols.nuget.org/download/symbols) がシンボル検索パスに追加されます。指定されていない場合、このオプションのデフォルトは false です。

cachePath": シンボルサーバーからダウンロードされたシンボルをキャッシュするディレクトリ。指定されていない場合、Windows ではデバッガーはデフォルトで %TEMP%\\SymbolCache を使用し、Linux および macOS では ~/.dotnet/symbolcache を使用します。

moduleFilter.mode: この値は "loadAllButExcluded" または "loadOnlyIncluded" のいずれかです。"loadAllButExcluded" モードでは、モジュールが 'excludedModules' 配列に含まれていない限り、デバッガーはすべてのモジュールのシンボルをロードします。"loadOnlyIncluded" モードでは、デバッガーは 'includedModules' 配列に含まれているか、'includeSymbolsNextToModules' 設定によって含まれていない限り、いかなるモジュールのシンボルもロードしようとしません。

loadAllButExcluded モードのプロパティ

moduleFilter.excludedModules: デバッガーがシンボルをロードすべきではないモジュールの配列。ワイルドカード (例: MyCompany.*.dll) がサポートされています。

loadOnlyIncluded モードのプロパティ

moduleFilter.includedModules: デバッガーがシンボルをロードすべきモジュールの配列。ワイルドカード (例: MyCompany.*.dll) がサポートされています。

moduleFilter.includeSymbolsNextToModules: true の場合、'includedModules' 配列に含まれていないモジュールであっても、デバッガーはモジュール自体と起動する実行可能ファイルの隣を確認しますが、シンボル検索リスト上のパスは確認しません。このオプションのデフォルトは 'true' です。

利用可能性

  • launch.json ✔️
  • settings.json ✔️ (csharp.debug.symbolOptions の下)
  • launchSettings.json ❌

Source Link オプション

Source Link は、NuGet パッケージから提供されるコードなど、別のコンピューターでビルドされたコードをデバッグしているときに、デバッガーが Web からダウンロードすることで一致するソースコードを自動的に表示できるようにする機能です。これが機能するには、デバッグしているコードの .pdb ファイルに、DLL 内のソースファイルをデバッガーがダウンロードできる URL にマッピングするデータが含まれている必要があります。Source Link の詳細については、https://aka.ms/SourceLinkSpec を参照してください。

launch.json の sourceLinkOptions 要素は、URL ごとに Source Link の動作をカスタマイズできます。これは、URL からその URL の Source Link オプションへのマップです。URL 名にはワイルドカードがサポートされています。現在、唯一のカスタマイズは、その URL に対して Source Link が有効になっているかどうかですが、将来的にはより多くのオプションが追加される可能性があります。

例

    "sourceLinkOptions": {
        "https://raw.githubusercontent.com/*": { "enabled": true },
        "*": { "enabled": false }
    }

この例では、GitHub URL に対して Source Link を有効にし、他のすべての URL に対して Source Link を無効にします。

このオプションのデフォルト値は、すべての URL に対して Source Link を有効にすることです。同様に、sourceLinkOptions マップにルールがない URL に対しては、Source Link が有効になります。

すべての URL に対して Source Link を無効にするには、"sourceLinkOptions": { "*": { "enabled": false } } を使用します。

複数のエントリが同じ URL をカバーしている場合、より具体的なエントリ (文字列の長さが長いエントリ) が使用されます。

現在、Source Link は認証なしでアクセスできるソースファイルに対してのみ機能します。したがって、例えば、デバッガーは GitHub のオープンソースプロジェクトからソースファイルをダウンロードできますが、プライベートな GitHub リポジトリや Visual Studio Team Services からはダウンロードできません。

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ❌

ターゲットアーキテクチャオプション (macOS M1)

Apple M1 上の .NET は、x86_64 と ARM64 の両方をサポートしています。デバッグ時には、デバッガーがアタッチするプロセスのアーキテクチャとデバッガーのアーキテクチャが一致している必要があります。一致しない場合、Unknown Error: 0x80131c3c が発生する可能性があります。

拡張機能は、PATH 内の dotnet --info の出力に基づいて targetArchitecture を解決しようとします。それ以外の場合は、VS Code と同じアーキテクチャを使用しようとします。

launch.json で targetArchitecture を設定することにより、この動作をオーバーライドできます。

例

    "targetArchitecture": "arm64"

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ❌

DevCert の確認

このオプションは、起動時にデバッガーが、HTTPS エンドポイントで実行される Web プロジェクトを開発するために使用される自己署名 HTTPS 証明書がコンピューターにあるかどうかを確認する必要があるかどうかを制御します。このために、dotnet dev-certs https --check --trust の実行を試み、証明書が見つからない場合は、ユーザーに作成を提案するプロンプトを表示します。ユーザーが承認した場合、拡張機能は dotnet dev-certs https --trust を実行して信頼された自己署名証明書を作成します。

指定されていない場合、serverReadyAction が設定されているときはデフォルトで true になります。このオプションは、Linux、VS Code リモート、および Web 用 VS Code のシナリオでは何も影響しません。

launch.json で checkForDevCert を false に設定することにより、この動作をオーバーライドできます。

例

    "checkForDevCert": "false"

利用可能性

  • launch.json ✔️
  • settings.json ❌
  • launchSettings.json ✔️ (useSSL として)

関連項目

6/6/2023