Konfigurieren des C#-Debuggers

Name: Visual Studio Code
Author: Microsoft

Sie können den C#-Debugger in Visual Studio Code mit einer launch.json, launchSettings.json oder Ihrer settings.json-Datei konfigurieren.

Anleitung: Kommandozeilenargumente festlegen

Bevor wir auf die Details aller möglichen Optionen eingehen, durchlaufen wir ein grundlegendes Szenario: Festlegen von Kommandozeilenargumenten für Ihr Programm. Diese Schritte funktionieren auch für die Aktualisierung anderer grundlegender Optionen wie Umgebungsvariablen oder des aktuellen Arbeitsverzeichnisses.

Ansatz 1: `launchSettings.json`

Für das C# Dev Kit ist die empfohlene Methode zum Debuggen, dass das C# Dev Kit automatisch die Einstellungen in der Projektdatei ermittelt. Das bedeutet, dass Sie entweder keine <workspace_root>/.vscode/launch.json-Datei haben oder, wenn Sie eine haben, für die aktive Konfiguration "type": "dotnet" gesetzt haben. Für Kommandozeilenargumente bedeutet "aus der Projektdatei ermitteln", den Wert aus <Project-Directory>/Properties/launchSettings.json zu übernehmen. Der Vorteil von launchSettings.json ist, dass Einstellungen zwischen Visual Studio Code, dem vollständigen Visual Studio und dotnet run geteilt werden können.

In diesem Fall sind hier die Schritte zum Festlegen der Kommandozeilenargumente

Navigieren Sie in der Workspace Explorer-Ansicht zu dem Verzeichnis des Projekts (.csproj-Datei), das Sie starten möchten
Erstellen Sie ein Properties-Verzeichnis, falls es noch nicht vorhanden ist
Erstellen Sie eine launchSettings.json-Datei, falls sie noch nicht vorhanden ist. Sie können den folgenden Text als Beispiel verwenden
Ändern Sie die Eigenschaft commandLineArgs auf die gewünschten Kommandozeilenargumente

Beispiel-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 Kommandozeilenargumente 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 Startkonfiguration coreclr oder clr, die Sie starten möchten
Bearbeiten Sie die Eigenschaft args. Dies kann entweder ein String oder ein Array von Strings sein

Konfigurieren von launchSettings.json

Mit dem C# Dev Kit können Sie Ihr launchSettings.json von Visual Studio verwenden, um es mit Visual Studio Code zu nutzen

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"
      }
    }
  }
}

Profil-Eigenschaften

commandLineArgs – Die Argumente, die an das auszuführende Ziel übergeben werden.
executablePath – Ein absoluter oder relativer Pfad zur ausführbaren Datei.
workingDirectory – Legt das Arbeitsverzeichnis des Befehls fest.
launchBrowser – Auf true setzen, wenn der Browser gestartet werden soll.
applicationUrl – Eine mit 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.

Konfigurierbare Optionen

Nachfolgend finden Sie häufige Optionen, die Sie möglicherweise beim Debuggen ändern möchten.

PreLaunchTask

Das Feld preLaunchTask führt die zugeordnete taskName in tasks.json aus, bevor Ihr Programm gedebuggt wird. Sie können die Standard-Build-Prelaunch-Aufgabe abrufen, indem Sie den Befehl Aufgaben: Aufgaben-Runner konfigurieren über die VS Code-Befehlspalette ausführen.

Dies erstellt eine Aufgabe, die dotnet build ausführt. Weitere Informationen finden Sie in der VS Code-Dokumentation zu Aufgaben.

Verfügbarkeit

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

Program

Das Feld program wird auf den Pfad der Anwendungs-DLL oder der .NET Core-Host-Ausführungsdatei 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"

<target-framework> ist das Framework, für das das zu debuggende Projekt erstellt wird. Dies wird normalerweise in der Projektdatei als 'TargetFramework'-Eigenschaft gefunden.
<project-name.dll> ist der Name der Build-Ausgabe-DLL des zu debuggenden Projekts. Dies ist normalerweise derselbe wie der Name der Projektdatei, jedoch mit der Erweiterung '.dll'.

Verfügbarkeit

launch.json ✔️
settings.json ❌
launchSettings.json ✔️ als executablePath

Cwd

Das Arbeitsverzeichnis des Zielprozesses.

Verfügbarkeit

launch.json ✔️
settings.json ❌
launchSettings.json ✔️ als workingDirectory

Args

Dies sind die Argumente, die Ihrem Programm übergeben werden.

Verfügbarkeit

launch.json ✔️
settings.json ❌
launchSettings.json ✔️ als commandLineArgs

Beim Einstieg stoppen

Wenn Sie am Einstiegspunkt des Ziels stoppen müssen, können Sie optional stopAtEntry auf "true" setzen.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.stopAtEntry
launchSettings.json ❌

Starten eines Webbrowsers

Die Standardvorlage 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 startet

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

Hinweise dazu

Wenn Sie NICHT möchten, dass der Browser automatisch startet, können Sie dieses Element einfach löschen (und ein launchBrowser-Element, falls Ihr launch.json stattdessen dies enthält).
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 Festlegen der Browser-URL. Dies kann nützlich sein, wenn die Zielanwendung auf einem anderen Computer oder in einem Container ausgeführt wird oder wenn applicationUrl einen speziellen Hostnamen hat (Beispiel: "applicationUrl": "http://*:1234/").
serverReadyAction ist ein neues Feature von VS Code. Es wird gegenüber dem bisherigen launchBrowser-Feature, das in den Debugger der C#-Erweiterung integriert ist, bevorzugt, da es funktioniert, wenn die C#-Erweiterung auf einem Remote-Computer ausgeführt wird, den Standardbrowser verwendet, der für VS Code konfiguriert ist, und auch die Verwendung eines Skript-Debuggers ermöglicht. Sie können launchBrowser stattdessen weiterhin verwenden, wenn keine dieser Funktionen für Sie wichtig ist. Sie können auch launchBrowser weiterhin verwenden, wenn Sie ein bestimmtes Programm ausführen möchten, anstatt den Standardbrowser zu starten.
Weitere Dokumentation für serverReadyAction finden Sie in den Release-Hinweisen von Visual Studio Code im Februar 2019.
So funktioniert das: VS Code analysiert die Ausgabe, die in die Konsole geschrieben wird. Wenn eine Zeile mit dem Muster übereinstimmt, wird ein Browser mit der URL gestartet, die vom Muster "erfasst" wurde.

Hier ist eine Erklärung, was das Muster bewirkt
- \\b : Passt an eine Wortgrenze an. Beachten Sie, dass \b eine Wortgrenze angibt, aber da dies in einem JSON-String steht, muss das \ maskiert werden, daher \\b.
- Now listening on: : Dies ist ein wörtlicher String, was bedeutet, dass der nächste Text Now listening on: sein muss.
- \\s+ : Passt auf ein oder mehrere Leerzeichen.
- ( : Dies ist der Beginn einer "Erfassungsgruppe". Dies kennzeichnet den Textbereich, der gespeichert und zum Starten des Browsers verwendet werden soll.
- http : Wörtlicher String.
- s? : Entweder das Zeichen s oder nichts.
- :// : Wörtlicher String.
- \\S+ : Ein oder mehrere Nicht-Leerzeichen-Zeichen.
- ) : Das Ende der Erfassungsgruppe.
Beide Formen des Browserstarts erfordern "console": "internalConsole", da der Browserstarter die Standardausgabe des Zielprozesses analysiert, um zu wissen, wann der Webserver sich selbst initialisiert hat.

Festlegen der Browser-URL

Wenn Sie die URL aus der Konsolenausgabe ignorieren möchten, können Sie die ( und ) aus dem Muster entfernen und uriFormat auf den gewünschten Wert setzen.

Beispiel

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

Wenn Sie die Portnummer aus der Konsolenausgabe, aber nicht den Hostnamen verwenden möchten, können Sie auch Folgendes 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, z. B. könnten Sie die standardmäßige Swagger-UI öffnen, indem Sie Folgendes 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 SwaggerUI eingerichtet hat, um dies tun zu können.

Verfügbarkeit

launch.json ✔️
settings.json ❌
launchSettings.json ✔️ mit launchBrowser und applicationUrl

Umgebungsvariablen

Umgebungsvariablen können mit diesem Schema an Ihr Programm übergeben werden

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

Verfügbarkeit

launch.json ✔️
settings.json ❌
launchSettings.json ✔️ als environmentVariables

Konsolen-(Terminal-)Fenster

Die Einstellung "console" steuert, in welchem Konsolen-(Terminal-)Fenster die Ziel-App gestartet wird. Sie kann auf einen der folgenden Werte gesetzt werden --

"internalConsole" (Standard): Die Konsoleneingabe (stdin) und -ausgabe (stdout/stderr) des Zielprozesses werden über die VS Code-Debugkonsole geleitet. Der Vorteil dieses Modus ist, dass Sie Nachrichten sowohl vom Debugger als auch vom Zielprogramm an einem Ort sehen können, sodass Sie keine wichtigen Nachrichten verpassen oder hin- und herschalten müssen. Dies ist nützlich für Programme mit einfachen Konsoleninteraktionen (Beispiel: Verwendung von Console.WriteLine und/oder Console.ReadLine). Dies sollte NICHT verwendet werden, wenn das Zielprogramm die vollständige Kontrolle über die Konsole benötigt, z. B. ein Programm, das die Cursorposition ändert, Console.ReadKey für die Eingabe verwendet usw. Siehe unten für Anweisungen zur Eingabe in die Konsole.
"integratedTerminal" : Der Zielprozess wird im integrierten Terminal von VS Code ausgeführt. Wählen Sie die Registerkarte Terminal in der Registerkartengruppe unter dem Editor aus, um mit Ihrer Anwendung zu interagieren. Wenn Sie diesen Modus verwenden, wird standardmäßig die Debugkonsole beim Starten des Debuggens nicht angezeigt. Wenn Sie launch.json verwenden, kann dies mit internalConsoleOptions konfiguriert werden.
"externalTerminal": Der Zielprozess wird in seinem eigenen externen Terminal ausgeführt. Wenn Sie diesen Modus verwenden, müssen Sie zwischen Visual Studio Code und dem externen Terminalfenster wechseln.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.console
launchSettings.json ❌

Hinweis: Die Einstellung csharp.debug.console wird nur für Konsolenprojekte verwendet, die mit dem Debug-Konfigurationstyp dotnet gestartet werden.

Eingabe 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. Dazu geben Sie, während das Programm ausgeführt wird, Text in das Eingabefeld am unteren Rand der Debugkonsole ein. Durch Drücken von Enter wird der Text an den Zielprozess gesendet. Beachten Sie, dass, wenn Sie Text in diesem Feld eingeben, während Ihr Programm unter dem Debugger angehalten ist, dieser Text als C#-Ausdruck ausgewertet wird und nicht an den Zielprozess gesendet wird.

Beispiel

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

`launchSettingsProfile` und `launchSettingsFilePath`

Obwohl die vollständige Unterstützung für launchSettings.json die Verwendung einer Startkonfiguration mit "type": "dotnet" erfordert, unterstützen die Debugger-Typen coreclr und clr auch eine eingeschränkte Teilmenge der Funktionalität von launchSettings.json. Dies ist nützlich für Benutzer, die die gleichen Einstellungen sowohl in Visual Studio Code als auch im vollständigen Visual Studio verwenden möchten.

Um festzulegen, welches launchSettings.json-Profil verwendet werden soll (oder um zu verhindern, dass es verwendet wird), setzen Sie die Option launchSettingsProfile

    "launchSettingsProfile": "ProfileNameGoesHere"

Dies würde dann beispielsweise myVariableName aus dieser Beispiel-launchSettings.json-Datei verwenden

{
  "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 unter {cwd}/Properties/launchSettings.json. Um diesen Pfad anzupassen, setzen Sie launchSettingsFilePath

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

Einschränkungen

Nur Profile mit "commandName": "Project" werden unterstützt.
Nur die Eigenschaften environmentVariables, applicationUrl und commandLineArgs werden unterstützt
Einstellungen in launch.json haben Vorrang vor Einstellungen in launchSettings.json. Wenn also args in launch.json bereits auf etwas anderes als einen leeren String/ein leeres Array gesetzt ist, werden die Inhalte von launchSettings.json ignoriert.

Verfügbarkeit

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

Source File Map

Sie können optional konfigurieren, wie Quelldateien geöffnet werden, indem Sie eine Map in dieser Form bereitstellen

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

In diesem Beispiel

C:\foo ist der ursprüngliche Speicherort für eine oder mehrere Quelldateien (Beispiel: program.cs), als ein Modul (Beispiel: MyCode.dll) kompiliert wurde. Es kann entweder ein Verzeichnis sein, das Quelldateien darunter enthält, oder ein vollständiger Pfad zu einer Quelldatei (Beispiel: c:\foo\program.cs). Es muss weder auf dem Computer, auf dem Visual Studio Code ausgeführt wird, noch, wenn Sie remote debuggen, auf dem Remote-Computer vorhanden sein. Der Debugger liest den Pfad zur Quelldatei aus der .pdb (Symbol-)Datei und transformiert den Pfad mithilfe dieser Map.
/home/me/foo ist der Pfad, unter dem die Quelldatei nun von Visual Studio Code gefunden werden kann.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.sourceFileMap
launchSettings.json ❌

Nur mein Code

Sie können justMyCode optional deaktivieren, indem Sie es auf "false" setzen. Sie sollten "Nur mein Code" deaktivieren, wenn Sie versuchen, in eine Bibliothek zu debuggen, die Sie heruntergeladen haben und für die keine Symbole vorhanden sind oder die optimiert ist.

    "justMyCode":false

"Nur mein Code" ist eine Reihe von Funktionen, die es einfacher machen, sich auf das Debuggen Ihres Codes zu konzentrieren, indem einige Details von optimierten Bibliotheken, die Sie möglicherweise verwenden, wie z. B. das .NET Framework selbst, ausgeblendet werden. Die wichtigsten Unterteile dieser Funktion sind --

Vom Benutzer nicht behandelte Ausnahmen: Stoppt den Debugger automatisch kurz bevor Ausnahmen vom Framework abgefangen werden
Schrittweises Vorgehen nur in meinem Code: Wenn beim schrittweisen Vorgehen Framework-Code zurück zu Benutzercode aufruft, wird automatisch angehalten.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.justMyCode
launchSettings.json ❌

Exakte Quelle erforderlich

Der Debugger erfordert, dass PDB- und Quellcode exakt übereinstimmen. Um dies zu ändern und das Übereinstimmen der Quellen zu deaktivieren, fügen Sie hinzu

    "requireExactSource": false

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.requireExactSource
launchSettings.json ❌

Eigenschaften und Operatoren schrittweise durchgehen

Der Debugger überspringt standardmäßig Eigenschaften und Operatoren in verwaltetem Code. In den meisten Fällen bietet dies eine bessere Debugging-Erfahrung. Um dies zu ändern und das schrittweise Durchgehen von Eigenschaften oder Operatoren zu aktivieren, fügen Sie hinzu

    "enableStepFiltering": false

Verfügbarkeit

launch.json ✔️
settings.json ✔️ als csharp.debug.enableStepFiltering
launchSettings.json ❌

Protokollierung

Sie können optional Meldungen aktivieren oder deaktivieren, die im Ausgabefenster protokolliert werden sollen. Die Flags im Protokollierungsfeld sind: 'exceptions', 'moduleLoad', 'programOutput', 'browserStdOut' und 'consoleUsageMessage'.

Es gibt auch erweiterte Optionen unter 'logging.diagnosticsLog', die zur Diagnose von Problemen mit dem Debugger gedacht sind.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ unter csharp.debug.logging
launchSettings.json ❌

PipeTransport

Wenn Sie möchten, dass der Debugger eine Verbindung zu einem Remote-Computer über eine andere ausführbare Datei herstellt, um die Standardeingabe 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 über Pipe-Transport finden Sie hier.

Informationen zur Konfiguration von Pipe-Transport 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 je nach 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 true, generiert der Debugger beim Laden eines optimierten Moduls (in Release-Konfiguration kompiliertes .dll) mit deaktivierten Optimierungen. Die Option ist standardmäßig false.

    "suppressJITOptimizations": true

Wie Optimierungen in .NET funktionieren: Wenn Sie Code debuggen, ist es einfacher, wenn dieser Code NICHT optimiert ist. Das liegt daran, dass der Compiler und die Laufzeitumgebung bei optimiertem Code Änderungen am erzeugten CPU-Code vornehmen, damit er schneller läuft, aber eine weniger direkte Zuordnung zum ursprünglichen Quellcode hat. Das bedeutet, dass Debugger häufig nicht in der Lage sind, den Wert lokaler Variablen anzuzeigen, und das schrittweise Debuggen sowie Breakpoints funktionieren möglicherweise nicht wie erwartet.

Normalerweise erstellt die Release-Build-Konfiguration optimierten Code und die Debug-Build-Konfiguration nicht. Die Optimize MSBuild-Eigenschaft steuert, ob der Compiler angewiesen wird, Code zu optimieren.

Im .NET-Ökosystem wird Code in einem zweistufigen Prozess von Quellcode zu CPU-Instruktionen umgewandelt: Zuerst wandelt der C#-Compiler den von Ihnen eingegebenen Text in eine zwischengeschaltete binäre Form namens MSIL um und schreibt diese in .dll-Dateien. Später wandelt die .NET-Laufzeitumgebung diese MSIL in CPU-Instruktionen um. Beide Schritte können bis zu einem gewissen Grad optimieren, aber der zweite Schritt, der von der .NET-Laufzeitumgebung durchgeführt wird, führt die signifikanteren Optimierungen durch.

Was die Option bewirkt: Diese Option steuert, was passiert, wenn eine DLL, die mit aktivierten Optimierungen kompiliert wurde, innerhalb des Zielprozesses geladen wird. Wenn diese Option false (Standardwert) ist, lässt die .NET-Laufzeitumgebung die Optimierungen aktiviert, wenn sie den MSIL-Code in CPU-Code kompiliert. Wenn die Option true ist, fordert der Debugger an, dass die Optimierungen deaktiviert werden.

Wann Sie diese Option verwenden sollten: Diese Option sollte verwendet werden, wenn Sie DLLs aus einer anderen Quelle heruntergeladen haben, z. B. aus einem NuGet-Paket, und Sie den Code in dieser DLL debuggen möchten. Damit dies funktioniert, müssen Sie auch die Symbol-(.pdb)-Datei für diese DLL finden.

Wenn Sie nur daran interessiert sind, lokal erstellten Code zu debuggen, ist es am besten, diese Option auf false zu lassen, da die Aktivierung dieser Option in einigen Fällen das Debuggen erheblich verlangsamen kann. Dafür gibt es zwei Gründe --

Optimierter Code läuft schneller. Wenn Sie die Optimierungen für viel Code deaktivieren, kann sich die Zeit summieren.
Wenn Sie "Nur mein Code" aktiviert haben, versucht der Debugger nicht einmal, Symbole für DLLs zu laden, die optimiert sind. 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 Auswirkung auf Module, die bereits zum Zeitpunkt des Anhängens des Debuggers geladen wurden.

2: Diese Option hat keine Auswirkung auf DLLs, die für nativen Code vorkompiliert (ngen'ed) wurden. Sie können jedoch die Verwendung von vorkompiliertem Code deaktivieren, indem Sie den Prozess mit der Umgebungsvariable COMPlus_ReadyToRun auf 0 setzen. Wenn Sie eine ältere Version von .NET Core (2.x) anvisieren, setzen Sie auch 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 ✔️ als csharp.debug.suppressJITOptimizations
launchSettings.json ❌

Symboloptionen

Das Element symbolOptions 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) zum Suchen nach .pdb-Dateien. Diese Verzeichnisse werden zusätzlich zu den Standardorten durchsucht, neben dem Modul und dem Pfad, an dem die .pdb ursprünglich abgelegt wurde.

searchMicrosoftSymbolServer: Wenn true, wird der Microsoft Symbol Server (https://msdl.microsoft.com/download/symbols) zum Pfad der Symbolsuche hinzugefügt. Wenn nicht angegeben, ist diese Option standardmäßig false.

searchNuGetOrgSymbolServer: Wenn true, wird der Nuget.org Symbol Server (https://symbols.nuget.org/download/symbols) zum Pfad der Symbolsuche hinzugefügt. Wenn nicht angegeben, ist diese Option standardmäßig false.

cachePath": Verzeichnis, in dem Symbole von Symbolservern heruntergeladen 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 wird über die Einstellung includeSymbolsNextToModules eingebunden.

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 für jedes Modul, das NICHT im Array includedModules enthalten ist, weiterhin neben dem Modul selbst und der gestarteten ausführbaren Datei, aber er prüft keine Pfade in der Symbolsuchliste. Diese Option ist standardmäßig auf true gesetzt.

Verfügbarkeit

launch.json ✔️
settings.json ✔️ unter csharp.debug.symbolOptions
launchSettings.json ❌

Source Link-Optionen

Source Link ist eine Funktion, die es ermöglicht, 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 abruft, indem er ihn aus dem Web herunterlädt. Damit dies funktioniert, enthalten die .pdb-Dateien des zu debuggenden Codes Daten, die die Quelldateien in der DLL einer URL zuordnen, von der der Debugger herunterladen kann. Weitere Informationen zu Source Link finden Sie unter https://aka.ms/SourceLinkSpec.

Das Element sourceLinkOptions in launch.json ermöglicht die Anpassung des Source Link-Verhaltens nach URL. Es ist eine Map von URL zu Source Link-Optionen für diese URL. Platzhalter sind im URL-Namen zulässig. Derzeit ist die einzige Anpassung, ob Source Link für diese URL aktiviert ist, aber zukünftig können 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 die Aktivierung von Source Link für alle URLs. Ebenso ist Source Link für jede URL aktiviert, die keine Regel in der Map sourceLinkOptions hat.

Um Source Link für alle URLs zu deaktivieren, verwenden Sie "sourceLinkOptions": { "*": { "enabled": false } }.

Wenn mehrere Einträge auf dieselbe URL zutreffen, wird der spezifischere Eintrag (der Eintrag mit der längeren Zeichenkette) verwendet.

Derzeit funktioniert Source Link nur für Quelldateien, die ohne Authentifizierung zugänglich sind. So kann der Debugger beispielsweise Quelldateien von Open-Source-Projekten auf GitHub herunterladen, aber er kann keine privaten GitHub-Repos oder Visual Studio Team Services herunterladen.

Verfügbarkeit

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

Ziellarchitekturoptionen (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, andernfalls 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 ❌

DevCert prüfen

Diese Option steuert, ob der Debugger beim Start prüft, ob der Computer über ein selbstsigniertes HTTPS-Zertifikat verfügt, das zum Entwickeln von Webprojekten mit HTTPS-Endpunkten verwendet wird. Dazu versucht er, dotnet dev-certs https --check --trust auszuführen. Wenn keine Zertifikate gefunden werden, wird der Benutzer aufgefordert, die Erstellung eines solchen vorzuschlagen. Wenn der Benutzer zustimmt, führt die Erweiterung dotnet dev-certs https --trust aus, um ein vertrauenswürdiges selbstsigniertes Zertifikat zu erstellen.

Wenn 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-Szenario.

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 ✔️ als useSSL

Siehe auch

6/6/2023

Konfigurieren des C#-Debuggers

Anleitung: Kommandozeilenargumente festlegen

Ansatz 1: launchSettings.json

Ansatz 2: launch.json

Konfigurieren von launchSettings.json

Profil-Eigenschaften

Konfigurierbare Optionen

PreLaunchTask

Program

Cwd

Args

Beim Einstieg stoppen

Starten eines Webbrowsers

Festlegen der Browser-URL

Umgebungsvariablen

Konsolen-(Terminal-)Fenster

Eingabe von Text in den Zielprozess bei Verwendung von internalConsole

launchSettingsProfile und launchSettingsFilePath

Source File Map

Nur mein Code

Exakte Quelle erforderlich

Eigenschaften und Operatoren schrittweise durchgehen

Protokollierung

PipeTransport

Betriebssystemspezifische Konfigurationen

JIT-Optimierungen unterdrücken

Symboloptionen

Eigenschaften

Eigenschaften für den Modus loadAllButExcluded

Eigenschaften für den Modus loadOnlyIncluded

Source Link-Optionen

Ziellarchitekturoptionen (macOS M1)

DevCert prüfen

Siehe auch

Ansatz 1: `launchSettings.json`

Ansatz 2: `launch.json`

`launchSettingsProfile` und `launchSettingsFilePath`