C#-Debugging konfigurieren
Sie können den C#-Debugger in Visual Studio Code mit einer launch.json-, launchSettings.json- oder Ihrer Benutzer-settings.json-Datei konfigurieren.
Schritt-für-Schritt-Anleitung: Festlegen von Befehlszeilenargumenten
Bevor wir auf die Details aller möglichen Optionen eingehen, gehen wir ein Basisszenario durch: das Festlegen von Befehlszeilenargumenten für Ihr Programm. Diese Schritte funktionieren auch für die Aktualisierung anderer grundlegender Optionen wie Umgebungsvariablen oder das aktuelle Arbeitsverzeichnis.
Ansatz 1: launchSettings.json
Für das C# Dev Kit ist die empfohlene Methode zum Debuggen, das C# Dev Kit automatisch anhand der Einstellungen in der Projektdatei ermitteln zu lassen, wie debuggt werden soll. Das bedeutet, dass Sie entweder keine <workspace_root>/.vscode/launch.json-Datei haben oder, falls Sie eine haben, "type": "dotnet" für die aktive Konfiguration eingestellt ist. Bei Befehlszeilenargumenten bedeutet "aus der Projektdatei ermitteln", den Wert aus <Project-Directory>/Properties/launchSettings.json zu ziehen. Der Vorteil von launchSettings.json besteht darin, dass Einstellungen zwischen Visual Studio Code, dem vollständigen Visual Studio und dotnet run geteilt werden können.
In diesem Fall sind dies die Schritte zum Festlegen der Befehlszeilenargumente
- Navigieren Sie in der Explorer-Ansicht des Arbeitsbereichs zum Verzeichnis des Projekts (.csproj-Datei), das Sie starten möchten
- Falls noch kein
Properties-Verzeichnis vorhanden ist, erstellen Sie es - Falls noch keine
launchSettings.json-Datei vorhanden ist, erstellen Sie eine; Sie können den unten stehenden Text als Beispiel verwenden - Ändern Sie die Eigenschaft
commandLineArgsin die gewünschten Befehlszeilenargumente
Beispiel für eine launchSettings.json-Datei:
{
"profiles": {
"MyLaunchProfileName": {
"commandName": "Project",
"commandLineArgs": "MyFirstArgument MySecondArgument"
}
}
}
Ansatz 2: launch.json
Wenn Sie den Debug-Adaptertyp coreclr oder clr in VS Code verwenden, werden Befehlszeilenargumente in Ihrer <workspace_root>/.vscode/launch.json gespeichert. Um sie in diesem Fall zu bearbeiten
- Öffnen Sie
<workspace_root>/.vscode/launch.json - Suchen Sie die
coreclr- oderclr-Startkonfiguration, die Sie ausführen möchten - Bearbeiten Sie die Eigenschaft
args. Dies kann entweder eine Zeichenfolge oder ein Array von Zeichenfolgen sein
Konfigurieren von launchSettings.json
Mit dem C# Dev Kit können Sie Ihre launchSettings.json aus Visual Studio übernehmen, um sie mit Visual Studio Code zu verwenden
Beispiel
{
"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"
}
}
}
}
Profileigenschaften
commandLineArgs– Die Argumente, die an das auszuführende Ziel übergeben werden sollen.executablePath– Ein absoluter oder relativer Pfad zur ausführbaren Datei.workingDirectory– Legt das Arbeitsverzeichnis des Befehls fest.launchBrowser– Auftruesetzen, wenn der Browser gestartet werden soll.applicationUrl– Eine durch Semikolon getrennte Liste von URLs, die für den Webserver konfiguriert werden sollen.sslPort– Der SSL-Port, der für die Website verwendet werden soll.httpPort– Der HTTP-Port, der für die Website verwendet werden soll.
Liste der konfigurierbaren Optionen
Nachfolgend finden Sie gängige Optionen, die Sie beim Debuggen möglicherweise ändern möchten.
PreLaunchTask
Das Feld preLaunchTask führt den zugehörigen taskName in tasks.json aus, bevor Ihr Programm debuggt wird. Sie können den Standard-Build-Prelaunch-Task erhalten, indem Sie den Befehl Tasks: Configure Tasks Runner über die VS Code-Befehlspalette ausführen.
Dadurch wird ein Task erstellt, der dotnet build ausführt. Weitere Informationen finden Sie in der VS Code-Dokumentation zu Tasks.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json❌
Programm
Das Programm-Feld wird auf den Pfad der Anwendungs-DLL oder der .NET Core Host-Programmdatei gesetzt, die gestartet werden soll.
Diese Eigenschaft hat normalerweise die Form: "${workspaceFolder}/bin/Debug/<target-framework>/<project-name.dll>".
Beispiel: "${workspaceFolder}/bin/Debug/netcoreapp1.1/MyProject.dll"
Wobei
- <target-framework> das Framework ist, für das das zu debuggende Projekt erstellt wird. Dies ist normalerweise in der Projektdatei als Eigenschaft 'TargetFramework' zu finden.
- <project-name.dll> der Name der Build-Ausgabe-DLL des zu debuggenden Projekts ist. Dies ist normalerweise derselbe wie der Name der Projektdatei, aber mit der Erweiterung '.dll'.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ alsexecutablePath
Cwd (Arbeitsverzeichnis)
Das Arbeitsverzeichnis des Zielprozesses.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ alsworkingDirectory
Args (Argumente)
Dies sind die Argumente, die an Ihr Programm übergeben werden.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ alscommandLineArgs
Am Einstiegspunkt anhalten (Stop at Entry)
Wenn Sie am Einstiegspunkt des Ziels anhalten müssen, können Sie optional stopAtEntry auf "true" setzen.
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.stopAtEntrylaunchSettings.json❌
Einen Webbrowser starten
Die Standard-Vorlage für launch.json (ab C#-Erweiterung v1.20.0) für ASP.NET Core-Projekte verwendet Folgendes, um VS Code so zu konfigurieren, dass ein Webbrowser gestartet wird, wenn ASP.NET gestartet wird
"serverReadyAction": {
"action": "openExternally",
"pattern": "\\bNow listening on:\\s+(https?://\\S+)"
}
Hinweise dazu
-
Wenn Sie NICHT möchten, dass der Browser automatisch gestartet wird, können Sie dieses Element (und ein
launchBrowser-Element, falls Ihrelaunch.jsonstattdessen dieses enthält) einfach löschen. -
Dieses Muster startet den Webbrowser unter Verwendung der URL, die ASP.NET Core in die Konsole schreibt. Wenn Sie die URL ändern möchten, siehe Angeben der Browser-URL. Dies kann nützlich sein, wenn die Zielanwendung auf einem anderen Computer oder Container ausgeführt wird oder wenn
applicationUrleinen speziellen Hostnamen hat (Beispiel:"applicationUrl": "http://*:1234/"). -
serverReadyActionist eine neue Funktion von VS Code. Sie wird gegenüber der vorherigenlaunchBrowser-Funktion empfohlen, die in den Debugger der C#-Erweiterung integriert ist, da sie funktioniert, wenn die C#-Erweiterung auf einem Remote-Computer ausgeführt wird, den für VS Code konfigurierten Standardbrowser verwendet und auch die Verwendung eines Skript-Debuggers ermöglicht. Sie könnenlaunchBrowserweiterhin verwenden, wenn keine dieser Funktionen für Sie wichtig ist. Sie könnenlaunchBrowserauch weiterhin verwenden, wenn Sie ein bestimmtes Programm anstelle des Standardbrowsers starten möchten. -
Weitere Dokumentation zu
serverReadyActionfinden Sie in den Visual Studio Code Release Notes vom Februar 2019. -
Dies funktioniert so, dass VS Code die Ausgabe ausliest, die an die Konsole gesendet wird. Wenn eine Zeile mit dem Muster übereinstimmt, wird ein Browser mit der URL gestartet, die durch das Muster "erfasst" wurde.
Hier ist eine Erklärung, was das Muster bewirkt
\\b: Entspricht einer Wortgrenze. Beachten Sie, dass\beine Wortgrenze angibt, aber da dies in einer JSON-Zeichenfolge steht, muss das\escaped werden, daher\\b.Now listening on:: Dies ist ein String-Literal, was bedeutet, dass der nächste TextNow listening on:lauten muss.\\s+: Entspricht einem oder mehreren Leerzeichen.(: Dies ist der Beginn einer "Erfassungsgruppe". Dies gibt den Textbereich an, der gespeichert und zum Starten des Browsers verwendet werden soll.http: String-Literal.s?: Entweder das Zeichensoder nichts.://: String-Literal.\\S+: Ein oder mehrere Nicht-Leerzeichen.): Das Ende der Erfassungsgruppe.
-
Beide Formen des Browserstarts erfordern
"console": "internalConsole", da der Browser-Starter die Standardausgabe des Zielprozesses scannt, um zu wissen, wann der Webserver sich initialisiert hat.
Angeben der Browser-URL
Wenn Sie die URL aus der Konsolenausgabe ignorieren möchten, können Sie die Klammern ( und ) aus dem Muster entfernen und uriFormat auf das setzen, was Sie starten möchten.
Beispiel
"serverReadyAction": {
"action": "openExternally",
"pattern": "\\bNow listening on:\\s+https?://\\S",
"uriFormat": "https://:1234"
}
Wenn Sie die Portnummer aus der Konsolenausgabe verwenden möchten, aber nicht den Hostnamen, können Sie auch so etwas verwenden
"serverReadyAction": {
"action": "openExternally",
"pattern": "\\bNow listening on:\\s+http://\\S+:([0-9]+)",
"uriFormat": "https://:%s"
}
Tatsächlich können Sie fast jede URL öffnen, zum Beispiel könnten Sie die Standard-Swagger-UI öffnen, indem Sie so etwas tun
"serverReadyAction": {
"action": "openExternally",
"pattern": "\\bNow listening on:\\s+http://\\S+:([0-9]+)",
"uriFormat": "https://:%s/swagger/index.html"
}
Hinweis: Sie müssen sicherstellen, dass Ihr Projekt für Swagger UI eingerichtet ist, um dies zu tun.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ mitlaunchBrowserundapplicationUrl
Umgebungsvariablen
Umgebungsvariablen können mit diesem Schema an Ihr Programm übergeben werden
"env": {
"myVariableName":"theValueGoesHere"
}
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ alsenvironmentVariables
Konsolen- (Terminal-) Fenster
Die Einstellung "console" steuert, in welchem Konsolen- (Terminal-) Fenster die Ziel-App gestartet wird. Sie kann auf einen dieser Werte gesetzt werden --
"internalConsole"(Standard): Die Konsoleneingabe (stdin) und -ausgabe (stdout/stderr) des Zielprozesses werden über die VS Code-Debug-Konsole geleitet. Der Vorteil dieses Modus besteht darin, dass Sie Meldungen sowohl vom Debugger als auch vom Zielprogramm an einem Ort sehen können, sodass Sie keine wichtigen Meldungen verpassen oder hin- und herwechseln müssen. Dies ist nützlich für Programme mit einfachen Konsoleninteraktionen (Beispiel: Verwendung vonConsole.WriteLineund/oderConsole.ReadLine). Dies sollte NICHT verwendet werden, wenn das Zielprogramm die volle Kontrolle über die Konsole benötigt, z. B. ein Programm, das die Cursorposition ändert,Console.ReadKeyfür die Eingabe verwendet usw. Siehe unten für Anweisungen zur Eingabe in die Konsole."integratedTerminal": Der Zielprozess wird innerhalb des integrierten Terminals von VS Code ausgeführt. Wählen Sie die Registerkarte Terminal in der Registerkartengruppe unter dem Editor aus, um mit Ihrer Anwendung zu interagieren. In diesem Modus wird die Debug-Konsole standardmäßig beim Starten des Debuggings nicht angezeigt. Bei Verwendung vonlaunch.jsonkann dies mitinternalConsoleOptionskonfiguriert werden."externalTerminal": Der Zielprozess wird in einem eigenen externen Terminal ausgeführt. In diesem Modus müssen Sie den Fokus zwischen Visual Studio Code und dem externen Terminalfenster wechseln.
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.consolelaunchSettings.json❌
Hinweis: Die Einstellung
csharp.debug.consolewird nur für Konsolenprojekte verwendet, die mit dem Debug-Konfigurationstypdotnetgestartet werden.
Eingeben von Text in den Zielprozess bei Verwendung von internalConsole
Wenn Sie internalConsole verwenden, können Sie Text in Visual Studio Code eingeben, der von Console.ReadLine und ähnlichen APIs, die von stdin lesen, zurückgegeben wird. Geben Sie dazu während der Ausführung des Programms Text in das Eingabefeld am unteren Rand der Debug-Konsole ein. Durch Drücken der Eingabetaste wird der Text an den Zielprozess gesendet. Beachten Sie: Wenn Sie Text in dieses Feld eingeben, während Ihr Programm unter dem Debugger angehalten ist, wird dieser Text als C#-Ausdruck ausgewertet und nicht an den Zielprozess gesendet.
Beispiel
launchSettingsProfile und launchSettingsFilePath
Während die volle Unterstützung für launchSettings.json die Verwendung einer Startkonfiguration mit "type": "dotnet" erfordert, unterstützen die Debugger-Typen coreclr und clr ebenfalls eine begrenzte Teilmenge der launchSettings.json-Funktionalität. Dies ist nützlich für Benutzer, die dieselben Einstellungen sowohl in Visual Studio Code als auch im vollständigen Visual Studio verwenden möchten.
Um zu konfigurieren, welches launchSettings.json-Profil verwendet werden soll (oder um dessen Verwendung zu verhindern), setzen Sie die Option launchSettingsProfile
"launchSettingsProfile": "ProfileNameGoesHere"
Was dann beispielsweise myVariableName aus dieser beispielhaften launchSettings.json-Datei verwenden würde
{
"profiles": {
"ProfileNameGoesHere": {
"commandName": "Project",
"environmentVariables": {
"myVariableName": "theValueGoesHere"
}
}
}
}
Wenn launchSettingsProfile NICHT angegeben ist, wird das erste Profil mit "commandName": "Project" verwendet.
Wenn launchSettingsProfile auf null/einen leeren String gesetzt ist, wird Properties/launchSettings.json ignoriert.
Standardmäßig sucht der Debugger nach launchSettings.json in {cwd}/Properties/launchSettings.json. Um diesen Pfad anzupassen, setzen Sie launchSettingsFilePath
"launchSettingsFilePath": "${workspaceFolder}/<Relative-Path-To-Project-Directory/Properties/launchSettings.json"
Einschränkungen
- Es werden nur Profile mit
"commandName": "Project"unterstützt. - Nur die Eigenschaften
environmentVariables,applicationUrlundcommandLineArgswerden unterstützt. - Einstellungen in
launch.jsonhaben Vorrang vor Einstellungen inlaunchSettings.json. Wenn zum Beispielargsinlaunch.jsonbereits auf etwas anderes als einen leeren String/ein leeres Array gesetzt ist, wird der Inhalt vonlaunchSettings.jsonignoriert.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json❌
Quelldateizuordnung (Source File Map)
Sie können optional konfigurieren, wie Quelldateien geöffnet werden, indem Sie eine Zuordnung in dieser Form bereitstellen
"sourceFileMap": {
"C:\\foo":"/home/me/foo"
}
In diesem Beispiel
C:\fooist der ursprüngliche Speicherort für eine oder mehrere Quelldateien (Beispiel:program.cs), als ein Modul (Beispiel: MyCode.dll) kompiliert wurde. Es kann sich entweder um ein Verzeichnis handeln, in dem sich Quelldateien befinden, oder um einen vollständigen Pfad zu einer Quelldatei (Beispiel:c:\foo\program.cs). Der Pfad muss weder auf dem Computer vorhanden sein, auf dem Visual Studio Code ausgeführt wird, noch auf dem Remote-Computer, wenn Sie Remote-Debugging betreiben. Der Debugger liest den Pfad zur Quelldatei aus der.pdb-Datei (Symbol-Datei) und transformiert den Pfad mithilfe dieser Zuordnung./home/me/fooist der Pfad, unter dem die Quelldatei jetzt von Visual Studio Code gefunden werden kann.
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.sourceFileMaplaunchSettings.json❌
Just My Code
Sie können justMyCode optional deaktivieren, indem Sie es auf "false" setzen. Sie sollten "Just My Code" deaktivieren, wenn Sie versuchen, in eine Bibliothek zu debuggen, die Sie heruntergeladen haben und die keine Symbole hat oder optimiert ist.
"justMyCode":false
Just My Code ist eine Reihe von Funktionen, die es erleichtern, sich auf das Debuggen Ihres eigenen Codes zu konzentrieren, indem einige Details optimierter Bibliotheken ausgeblendet werden, die Sie möglicherweise verwenden, wie z. B. das .NET Framework selbst. Die wichtigsten Unterpunkte dieser Funktion sind --
- Nicht vom Benutzer behandelte Ausnahmen: Hält den Debugger automatisch an, kurz bevor Ausnahmen vom Framework abgefangen werden.
- Just My Code-Stepping: Wenn beim Durchlaufen (Stepping) Framework-Code zurück in den Benutzercode ruft, wird automatisch angehalten.
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.justMyCodelaunchSettings.json❌
Exakte Quelle anfordern
Der Debugger erfordert, dass PDB und Quellcode exakt übereinstimmen. Um dies zu ändern und die Anforderung der Übereinstimmung zu deaktivieren, fügen Sie hinzu
"requireExactSource": false
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.requireExactSourcelaunchSettings.json❌
Einstieg in Eigenschaften und Operatoren
Der Debugger überspringt standardmäßig Eigenschaften und Operatoren in verwaltetem Code. In den meisten Fällen bietet dies ein besseres Debugging-Erlebnis. Um dies zu ändern und den Einstieg in Eigenschaften oder Operatoren zu ermöglichen, fügen Sie hinzu
"enableStepFiltering": false
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.enableStepFilteringlaunchSettings.json❌
Protokollierung (Logging)
Sie können optional Meldungen aktivieren oder deaktivieren, die im Ausgabefenster protokolliert werden sollen. Die Flags im Feld "logging" sind: 'exceptions', 'moduleLoad', 'programOutput', 'browserStdOut' und 'consoleUsageMessage'.
Es gibt auch erweiterte Optionen unter 'logging.diagnosticsLog', die für die Diagnose von Problemen mit dem Debugger gedacht sind.
Verfügbarkeit
launch.json✔️settings.json✔️ untercsharp.debug.logginglaunchSettings.json❌
Pipe-Transport
Wenn der Debugger eine Verbindung zu einem Remote-Computer herstellen muss und dabei eine andere ausführbare Datei verwenden soll, um die Standardein- und -ausgabe zwischen VS Code und dem .NET Core-Debugger-Backend (vsdbg) weiterzuleiten, fügen Sie das Feld pipeTransport gemäß diesem Schema hinzu
"pipeTransport": {
"pipeProgram": "ssh",
"pipeArgs": [ "-T", "ExampleAccount@ExampleTargetComputer" ],
"debuggerPath": "~/vsdbg/vsdbg",
"pipeCwd": "${workspaceFolder}",
"quoteArgs": true
}
Weitere Informationen zum Pipe-Transport finden Sie hier.
Informationen zum Konfigurieren des Pipe-Transports für das Windows-Subsystem für Linux (WSL) finden Sie hier.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json❌
Betriebssystemspezifische Konfigurationen
Wenn es spezifische Befehle gibt, die pro Betriebssystem geändert werden müssen, können Sie die Felder 'windows', 'osx' oder 'linux' verwenden. Sie können jedes der oben genannten Felder für das spezifische Betriebssystem ersetzen.
JIT-Optimierungen unterdrücken
Der .NET-Debugger unterstützt die folgende Option. Wenn diese auf "true" gesetzt ist und ein optimiertes Modul (eine im Release-Modus kompilierte .dll) im Zielprozess geladen wird, fordert der Debugger den Just-In-Time-Compiler auf, Code mit deaktivierten Optimierungen zu generieren. Die Option ist standardmäßig auf "false" gesetzt.
"suppressJITOptimizations": true
Wie Optimierungen in .NET funktionieren: Wenn Sie versuchen, Code zu debuggen, ist dies einfacher, wenn dieser Code NICHT optimiert ist. Denn wenn Code optimiert ist, nehmen Compiler und Runtime Änderungen am ausgegebenen CPU-Code vor, damit er schneller läuft, aber er hat dann eine weniger direkte Zuordnung zum ursprünglichen Quellcode. Das bedeutet, dass Debugger häufig nicht in der Lage sind, Ihnen den Wert lokaler Variablen anzuzeigen, und Code-Stepping sowie Haltepunkte funktionieren möglicherweise nicht wie erwartet.
Normalerweise erstellt die Release-Build-Konfiguration optimierten Code und die Debug-Build-Konfiguration nicht. Die MSBuild-Eigenschaft Optimize steuert, ob der Compiler angewiesen wird, den Code zu optimieren.
Im .NET-Ökosystem wird Code in einem zweistufigen Prozess von der Quelle in CPU-Befehle umgewandelt: Zuerst konvertiert der C#-Compiler den von Ihnen eingegebenen Text in eine binäre Zwischenform namens MSIL und schreibt diese in .dll-Dateien. Später konvertiert die .NET-Runtime diese MSIL in CPU-Befehle. Beide Schritte können bis zu einem gewissen Grad optimieren, aber der zweite Schritt, der von der .NET-Runtime ausgeführt wird, führt die signifikanteren Optimierungen durch.
Was bewirkt die Option: Diese Option steuert, was passiert, wenn eine DLL, die mit aktivierten Optimierungen kompiliert wurde, innerhalb des Zielprozesses geladen wird. Wenn diese Option auf "false" steht (Standardwert), lässt die .NET-Runtime beim Kompilieren des MSIL-Codes in CPU-Code die Optimierungen aktiviert. Wenn die Option "true" ist, fordert der Debugger an, dass die Optimierungen deaktiviert werden.
Wann sollten Sie diese Option verwenden: Diese Option sollte verwendet werden, wenn Sie DLLs aus einer anderen Quelle heruntergeladen haben, z. B. ein NuGet-Paket, und Sie den Code in dieser DLL debuggen möchten. Damit dies funktioniert, müssen Sie auch die Symboldatei (.pdb) für diese DLL finden.
Wenn Sie nur daran interessiert sind, Code zu debuggen, den Sie lokal erstellen, lassen Sie diese Option am besten auf "false", da die Aktivierung dieser Option in einigen Fällen das Debugging erheblich verlangsamt. Es gibt zwei Gründe für diese Verlangsamung --
- Optimierter Code läuft schneller. Wenn Sie die Optimierungen für viel Code ausschalten, kann sich die Zeit summieren.
- Wenn "Just My Code" aktiviert ist, versucht der Debugger nicht einmal, Symbole für optimierte DLLs zu laden. Das Finden von Symbolen kann lange dauern.
Einschränkungen dieser Option: Es gibt zwei Situationen, in denen diese Option NICHT funktioniert
1: In Situationen, in denen Sie den Debugger an einen bereits laufenden Prozess anhängen, hat diese Option keine Auswirkungen auf Module, die zum Zeitpunkt des Anhängens des Debuggers bereits geladen waren.
2: Diese Option hat keine Auswirkungen auf DLLs, die bereits zu nativem Code vorkompiliert (ngen'ed) wurden. Sie können die Verwendung von vorkompiliertem Code jedoch deaktivieren, indem Sie den Prozess mit der Umgebungsvariablen COMPlus_ReadyToRun auf 0 gesetzt starten. Wenn Sie auf eine ältere Version von .NET Core (2.x) abzielen, setzen Sie zusätzlich COMPlus_ZapDisable auf '1'. Wenn Sie unter dem Debugger starten, kann diese Konfiguration durch Hinzufügen dieser Einstellung zu launch.json vorgenommen werden
"env": {
"COMPlus_ZapDisable": "1",
"COMPlus_ReadyToRun": "0"
}
Verfügbarkeit
launch.json✔️settings.json✔️ alscsharp.debug.suppressJITOptimizationslaunchSettings.json❌
Symbol-Optionen
Das symbolOptions-Element ermöglicht die Anpassung der Art und Weise, wie der Debugger nach Symbolen sucht. Beispiel
"symbolOptions": {
"searchPaths": [
"~/src/MyOtherProject/bin/debug",
"https://my-companies-symbols-server"
],
"searchMicrosoftSymbolServer": true,
"searchNuGetOrgSymbolServer": true,
"cachePath": "/symcache",
"moduleFilter": {
"mode": "loadAllButExcluded",
"excludedModules": [ "DoNotLookForThisOne*.dll" ]
}
}
Eigenschaften
searchPaths: Array von Symbolserver-URLs (Beispiel: https://msdl.microsoft.com/download/symbols) oder Verzeichnissen (Beispiel: /build/symbols), in denen nach .pdb-Dateien gesucht werden soll. Diese Verzeichnisse werden zusätzlich zu den Standardspeicherorten durchsucht (neben dem Modul und dem Pfad, an dem die .pdb ursprünglich abgelegt wurde).
searchMicrosoftSymbolServer: Wenn true, wird der Microsoft Symbolserver (https://msdl.microsoft.com/download/symbols) zum Symbolsuchpfad hinzugefügt. Wenn nicht angegeben, ist diese Option standardmäßig false.
searchNuGetOrgSymbolServer: Wenn true, wird der NuGet.org Symbolserver (https://symbols.nuget.org/download/symbols) zum Symbolsuchpfad hinzugefügt. Wenn nicht angegeben, ist diese Option standardmäßig false.
cachePath: Verzeichnis, in dem von Symbolservern heruntergeladene Symbole zwischengespeichert werden sollen. Wenn nicht angegeben, verwendet der Debugger unter Windows standardmäßig %TEMP%\\SymbolCache und unter Linux und macOS standardmäßig ~/.dotnet/symbolcache.
moduleFilter.mode: Dieser Wert ist entweder "loadAllButExcluded" oder "loadOnlyIncluded". Im Modus "loadAllButExcluded" lädt der Debugger Symbole für alle Module, es sei denn, das Modul befindet sich im Array 'excludedModules'. Im Modus "loadOnlyIncluded" versucht der Debugger NICHT, Symbole für irgendein Modul zu laden, es sei denn, es befindet sich im Array 'includedModules' oder es ist über die Einstellung 'includeSymbolsNextToModules' eingeschlossen.
Eigenschaften für den Modus "loadAllButExcluded"
moduleFilter.excludedModules: Array von Modulen, für die der Debugger KEINE Symbole laden soll. Platzhalter (Beispiel: MyCompany.*.dll) werden unterstützt.
Eigenschaften für den Modus "loadOnlyIncluded"
moduleFilter.includedModules: Array von Modulen, für die der Debugger Symbole laden soll. Platzhalter (Beispiel: MyCompany.*.dll) werden unterstützt.
moduleFilter.includeSymbolsNextToModules: Wenn "true", prüft der Debugger bei Modulen, die NICHT im Array 'includedModules' enthalten sind, dennoch direkt neben dem Modul selbst und der startenden ausführbaren Datei, prüft jedoch keine Pfade in der Symbolsuchliste. Diese Option ist standardmäßig auf 'true' gesetzt.
Verfügbarkeit
launch.json✔️settings.json✔️ untercsharp.debug.symbolOptionslaunchSettings.json❌
Source Link-Optionen
Source Link ist eine Funktion, die bewirkt, dass der Debugger beim Debuggen von Code, der auf einem anderen Computer erstellt wurde (z. B. Code aus einem NuGet-Paket), automatisch den passenden Quellcode anzeigen kann, indem er ihn aus dem Web herunterlädt. Damit dies funktioniert, enthalten die .pdb-Dateien für den Code, den Sie debuggen, Daten, die die Quelldateien in der DLL einer URL zuordnen, von der der Debugger sie herunterladen kann. Weitere Informationen zu Source Link finden Sie unter https://aka.ms/SourceLinkSpec.
Das sourceLinkOptions-Element in launch.json ermöglicht die Anpassung des Source Link-Verhaltens nach URL. Es ist eine Zuordnung von URL zu Source Link-Optionen für diese URL. Platzhalter im URL-Namen werden unterstützt. Derzeit besteht die einzige Anpassungsmöglichkeit darin, ob Source Link für diese URL aktiviert ist, aber in Zukunft könnten weitere Optionen hinzugefügt werden.
Beispiel
"sourceLinkOptions": {
"https://raw.githubusercontent.com/*": { "enabled": true },
"*": { "enabled": false }
}
Dieses Beispiel aktiviert Source Link für GitHub-URLs und deaktiviert Source Link für alle anderen URLs.
Der Standardwert dieser Option ist, Source Link für alle URLs zu aktivieren. Ebenso ist Source Link für jede URL aktiviert, die keine Regel in der sourceLinkOptions-Zuordnung hat.
Um Source Link für alle URLs zu deaktivieren, verwenden Sie "sourceLinkOptions": { "*": { "enabled": false } }.
Wenn mehrere Einträge dieselbe URL abdecken, wird der spezifischere Eintrag (der Eintrag mit der längeren Zeichenfolge) verwendet.
Derzeit funktioniert Source Link nur für Quelldateien, auf die ohne Authentifizierung zugegriffen werden kann. So kann der Debugger beispielsweise Quelldateien von Open-Source-Projekten auf GitHub herunterladen, aber er kann sie nicht von privaten GitHub-Repos oder von Visual Studio Team Services herunterladen.
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json❌
Optionen für die Zielarchitektur (macOS M1)
.NET auf Apple M1 unterstützt sowohl x86_64 als auch ARM64. Beim Debuggen müssen die Architektur des Prozesses, an den der Debugger angehängt wird, und die des Debuggers übereinstimmen. Wenn sie nicht übereinstimmen, kann dies zu Unknown Error: 0x80131c3c führen.
Die Erweiterung versucht, targetArchitecture basierend auf der Ausgabe von dotnet --info im PATH aufzulösen, ansonsten versucht sie, dieselbe Architektur wie VS Code zu verwenden.
Sie können dieses Verhalten überschreiben, indem Sie targetArchitecture in Ihrer launch.json festlegen.
Beispiel
"targetArchitecture": "arm64"
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json❌
Auf DevCert prüfen
Diese Option steuert, ob der Debugger beim Start prüfen soll, ob der Computer über ein selbstsigniertes HTTPS-Zertifikat verfügt, das zur Entwicklung von Webprojekten verwendet wird, die auf https-Endpunkten ausgeführt werden. Hierzu versucht er, dotnet dev-certs https --check --trust auszuführen. Wenn keine Zertifikate gefunden werden, wird der Benutzer gefragt, ob eines erstellt werden soll. Wenn der Benutzer zustimmt, führt die Erweiterung dotnet dev-certs https --trust aus, um ein vertrauenswürdiges selbstsigniertes Zertifikat zu erstellen.
Falls nicht angegeben, ist der Standardwert "true", wenn serverReadyAction gesetzt ist. Diese Option hat keine Auswirkungen unter Linux, VS Code Remote und VS Code für das Web.
Sie können dieses Verhalten überschreiben, indem Sie checkForDevCert in Ihrer launch.json auf "false" setzen.
Beispiel
"checkForDevCert": "false"
Verfügbarkeit
launch.json✔️settings.json❌launchSettings.json✔️ alsuseSSL