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 間で設定を共有できることです。
この場合、コマンドライン引数を設定する手順は次のとおりです。
- ワークスペースエクスプローラービューで、起動したいプロジェクト (.csproj ファイル) のディレクトリに移動します。
Propertiesディレクトリがまだない場合は作成します。launchSettings.jsonファイルがまだない場合は作成します。以下のテキストを例として使用できます。commandLineArgsプロパティを、コマンドライン引数として設定したい値に変更します。
launchSettings.json ファイルの例:
{
"profiles": {
"MyLaunchProfileName": {
"commandName": "Project",
"commandLineArgs": "MyFirstArgument MySecondArgument"
}
}
}
アプローチ 2: launch.json
VS Code で coreclr または clr デバッグアダプタータイプを使用している場合、コマンドライン引数は <workspace_root>/.vscode/launch.json に保存されます。この場合、それらを編集するには
<workspace_root>/.vscode/launch.jsonを開きます。- 起動したい
coreclrまたはclr起動構成を見つけます。 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 で関連付けられた taskName を実行します。VS Code のコマンドパレットから **Tasks: Configure Tasks Runner** コマンドを実行することで、デフォルトのビルドプリローンチタスクを取得できます。
これにより、dotnet build を実行するタスクが作成されます。詳細については、VS Code のタスクドキュメントを参照してください。
可用性
launch.json✔️settings.json❌launchSettings.json❌
プログラム
program フィールドは、起動するアプリケーションの 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+)"
}
これに関する注意点
-
ブラウザを自動的に起動したくない場合は、この要素 (および
launch.jsonにlaunchBrowser要素がある場合はそれも) を削除するだけです。 -
このパターンは、ASP.NET Core がコンソールに書き込む URL を使用して Web ブラウザを起動します。URL を変更したい場合は、ブラウザの URL の指定を参照してください。これは、ターゲットアプリケーションが別のマシンまたはコンテナで実行されている場合、または
applicationUrlが特殊なホスト名を持っている場合 (例:"applicationUrl": "http://*:1234/") に役立つ可能性があります。 -
serverReadyActionは VS Code の新機能です。これは、C# 拡張機能のデバッガーに組み込まれている以前のlaunchBrowser機能よりも推奨されます。これは、C# 拡張機能がリモートマシンで実行されている場合でも機能し、VS Code 用に構成されたデフォルトのブラウザを使用し、スクリプトデバッガーも使用できます。これらの機能がいずれも重要でない場合は、代わりにlaunchBrowserを使い続けることができます。デフォルトのブラウザを起動する代わりに特定のプログラムを実行したい場合も、launchBrowserを使い続けることができます。 -
serverReadyActionの詳細については、Visual Studio Code 2019 年 2 月のリリースノートを参照してください。 -
これは、VS Code がコンソールに出力されたものをスクレイピングすることで機能します。行がパターンに一致する場合、パターンによって「キャプチャ」された URL に対してブラウザを起動します。
パターンが何をするかの説明は次のとおりです。
\\b: 単語の境界に一致します。\bは単語の境界を示しますが、これは JSON 文字列内にあるため、\はエスケープする必要があり、\\bとなります。Now listening on:: これは文字列リテラルであり、次のテキストがNow listening on:である必要があることを意味します。\\s+: 1 つ以上のスペース文字に一致します。(: これは「キャプチャグループ」の始まりです。これは、ブラウザを起動するために保存および使用されるテキストの領域を示します。http: 文字列リテラル。s?: 文字sまたは何もありません。://: 文字列リテラル。\\S+: 1 つ以上の非空白文字。): キャプチャグループの終わり。
-
どちらのブラウザ起動形式も
"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#式として評価され、ターゲットプロセスには送信されないことに注意してください。
例
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"
制限事項
"commandName": "Project"を持つプロファイルのみがサポートされます。environmentVariables、applicationUrl、commandLineArgsプロパティのみがサポートされます。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❌
ロギング
出力ウィンドウにログを記録するメッセージをオプションで有効または無効にできます。ログフィールドのフラグは、「例外」、「モジュールロード」、「プログラム出力」、「ブラウザStdOut」、「コンソール使用メッセージ」です。
デバッガーの問題を診断することを目的とした、「logging.diagnosticsLog」の下に高度なオプションもあります。
可用性
launch.json✔️settings.json✔️csharp.debug.loggingの下launchSettings.json❌
PipeTransport
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 化) された 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❌
ソースリンクオプション
ソースリンクは、nuget パッケージから取得したコードなど、別のコンピューターでビルドされたコードをデバッグしているときに、デバッガーが Web からダウンロードすることで一致するソースコードを自動的に表示できる機能です。これが機能するためには、デバッグしているコードの .pdb ファイルに、DLL 内のソースファイルをデバッガーがダウンロードできる URL にマッピングするデータが含まれている必要があります。ソースリンクに関する詳細情報は、https://aka.ms/SourceLinkSpec で確認できます。
launch.json の sourceLinkOptions 要素を使用すると、URL ごとにソースリンクの動作をカスタマイズできます。これは、URL からその URL のソースリンクオプションへのマップです。URL 名ではワイルドカードがサポートされています。現在、カスタマイズできるのは、その URL に対してソースリンクが有効になっているかどうかだけですが、将来さらに多くのオプションが追加される可能性があります。
例
"sourceLinkOptions": {
"https://raw.githubusercontent.com/*": { "enabled": true },
"*": { "enabled": false }
}
この例では、GitHub URL のソースリンクを有効にし、他のすべての URL のソースリンクを無効にします。
このオプションのデフォルト値は、すべての URL に対してソースリンクを有効にすることです。同様に、sourceLinkOptions マップにルールがない URL はすべてソースリンクが有効になります。
すべての URL のソースリンクを無効にするには、"sourceLinkOptions": { "*": { "enabled": false } } を使用します。
複数のエントリが同じ URL をカバーしている場合、より具体的なエントリ (文字列長が長いエントリ) が使用されます。
現在、ソースリンクは認証なしでアクセスできるソースファイルでのみ機能します。そのため、たとえば、デバッガーは 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として