Freigeben über


Debuggen von ASP.NET Core-Apps

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

Warnung

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Supportrichtlinie für .NET und .NET Core. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

In diesem Artikel wird beschrieben, wie Sie Blazor-Apps debuggen, einschließlich des Debuggens von Blazor WebAssembly-Apps mit Browserentwicklertools oder einer integrierten Entwicklungsumgebung (IDE).

Blazor Web Apps können in einer IDE, Visual Studio oder Visual Studio Code debuggt werden.

Blazor WebAssembly-Apps können debuggt werden:

  • In Visual Studio oder Visual Studio Code.
  • Verwenden von Browserentwicklertools in Chromium-basierten Browsern, unter anderem in Microsoft Edge, Google Chrome und Firefox.

Zu den verfügbaren Szenarien für das Debuggen von Blazor WebAssembly gehören:

  • Festlegen und Entfernen von Breakpoints.
  • Ausführen der App mit Debugunterstützung in IDEs
  • Ausführung von Code in Einzelschritten
  • Wiederaufnehmen der Codeausführung mit Tastenkombinationen in IDEs
  • Beobachten der Werte lokaler Variablen im Fenster Lokale Variablen
  • Anzeigen der Aufrufliste einschließlich Aufrufketten zwischen JavaScript und .NET
  • Verwenden Sie einen Symbolserver zum Debuggen, der durch Visual Studio-Einstellungen konfiguriert wird.

Nicht unterstützte Szenarien umfassen:

Blazor Server-Apps können in einer IDE, Visual Studio oder Visual Studio Code debuggt werden.

Blazor WebAssembly-Apps können debuggt werden:

  • In Visual Studio oder Visual Studio Code.
  • Verwenden von Browserentwicklertools in Chromium-basierten Browsern, unter anderem Microsoft Edge und Google Chrome.

Nicht unterstützte Szenarien für Blazor WebAssembly-Apps umfassen:

  • Festlegen und Entfernen von Breakpoints.
  • Ausführen der App mit Debugunterstützung in IDEs
  • Ausführung von Code in Einzelschritten
  • Wiederaufnehmen der Codeausführung mit Tastenkombinationen in IDEs
  • Beobachten der Werte lokaler Variablen im Fenster Lokale Variablen
  • Anzeigen der Aufrufliste einschließlich Aufrufketten zwischen JavaScript und .NET
  • Debuggen Sie in nicht lokalen Szenarien (z. B. Windows-Subsystem für Linux (WSL) oder Visual Studio Codespaces).
  • Verwenden Sie einen Symbolserver zum Debuggen.

Blazor Server-Apps können in einer IDE, Visual Studio oder Visual Studio Code debuggt werden.

Blazor WebAssembly-Apps können debuggt werden:

  • In Visual Studio oder Visual Studio Code.
  • Verwenden von Browserentwicklertools in Chromium-basierten Browsern, unter anderem Microsoft Edge und Google Chrome.

Nicht unterstützte Szenarien für Blazor WebAssembly-Apps umfassen:

  • Festlegen und Entfernen von Breakpoints.
  • Ausführen der App mit Debugunterstützung in IDEs
  • Ausführung von Code in Einzelschritten
  • Wiederaufnehmen der Codeausführung mit Tastenkombinationen in IDEs
  • Beobachten der Werte lokaler Variablen im Fenster Lokale Variablen
  • Anzeigen der Aufrufliste einschließlich Aufrufketten zwischen JavaScript und .NET
  • Erreichen von Breakpoints während des App-Starts, bevor der Debugproxy ausgeführt wird. Dazu gehören Breakpoints in der Program-Datei und Breakpoints in den OnInitialized{Async}-Lebenszyklusmethoden von Komponenten, die von der ersten von der App angeforderten Seite geladen werden.
  • Debuggen Sie in nicht lokalen Szenarien (z. B. Windows-Subsystem für Linux (WSL) oder Visual Studio Codespaces).
  • Verwenden Sie einen Symbolserver zum Debuggen.

Voraussetzungen

In diesem Abschnitt werden die Voraussetzungen für das Debuggen erläutert.

Browservoraussetzungen

Die neueste Version der folgenden Browser:

  • Google Chrome
  • Microsoft Edge
  • Firefox (nur Browser-Entwicklertools)

Für das Debuggen ist die neueste Version der folgenden Browser erforderlich:

  • Google Chrome (Standard)
  • Microsoft Edge

Stellen Sie sicher, dass Firewalls oder Proxys die Kommunikation mit dem Debugproxy (NodeJS-Prozess) nicht blockieren. Weitere Informationen finden Sie im Abschnitt Firewallkonfiguration.

Hinweis

Safari von Apple unter macOS wird aktuell nicht unterstützt.

IDE-Voraussetzungen

Die neueste Version von Visual Studio oder Visual Studio Code ist erforderlich.

Voraussetzungen für Visual Studio Code

Visual Studio Code erfordert das C# Dev Kit für Visual Studio Code (Erste Schritte mit C# in VS Code). Filtern Sie im Visual Studio Code Extensions-Marketplace die Erweiterungsliste mit „c# dev kit“, um die Erweiterung zu finden:

C# Dev Kit im Visual Studio Code-Erweiterungs-Marketplace

Durch die automatische Installation des C# Dev Kit werden die folgenden zusätzlichen Erweiterungen installiert:

Wenn Warnungen oder Fehler auftreten, können Sie ein Problem öffnen (microsoft/vscode-dotnettools GitHub-Repository) öffnen, welches das Problem beschreibt.

App-Konfigurationsvoraussetzungen

Die Anleitung in diesem Unterabschnitt gilt für das clientseitige Debuggen.

Öffnen Sie die Properties/launchSettings.json-Datei des Startprojekts. Bestätigen Sie das Vorhandensein der folgenden inspectUri-Eigenschaft in jedem Startprofil des Knotens profiles der Datei. Wenn die folgende Eigenschaft nicht vorhanden ist, fügen Sie sie zu jedem Profil hinzu:

"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"

Die inspectUri-Eigenschaft:

  • ermöglicht der IDE, zu ermitteln, ob es sich bei einer App um eine Blazor-App handelt.
  • weist die Skriptdebugginginfrastruktur zum Herstellen einer Verbindung mit dem Browser über den Debugproxy von Blazor an.

Die Platzhalterwerte für das WebSocket-Protokoll (wsProtocol), den Host (url.hostname), den Port (url.port) und den Inspektor-URI im gestarteten Browser (browserInspectUri) werden vom Framework bereitgestellt.

Pakete

Blazor Web Apps: Microsoft.AspNetCore.Components.WebAssembly.Server: Verweist auf ein internes Paket (Microsoft.NETCore.BrowserDebugHost.Transport) für Assemblys, die den Browser-Debughost teilen.

Blazor Server: Microsoft.AspNetCore.Components.WebAssembly.ServerVerweist auf ein internes Paket (Microsoft.NETCore.BrowserDebugHost.Transport) für Assemblys, die den Browser-Debughost teilen.

Standalone Blazor WebAssembly: Microsoft.AspNetCore.Components.WebAssembly.DevServer: Entwicklungsserver für die Verwendung beim Erstellen von Blazor-Apps. Ruft UseWebAssemblyDebugging intern auf, um Middleware zum Debuggen Blazor WebAssembly von Apps innerhalb Chromium-Entwicklertools hinzuzufügen.

Blazor WebAssembly gehostet:

Hinweis

Eine Anleitung zum Hinzufügen von Paketen zu .NET-Anwendungen finden Sie in den Artikeln unter Pakete installieren und verwalten unter Workflow für die Paketnutzung (NuGet-Dokumentation). Überprüfen Sie unter NuGet.org, ob die richtige Paketversion verwendet wird.

Debuggen einer Blazor Web App-App in einer IDE

Im Beispiel in diesem Abschnitt wird davon ausgegangen, dass Sie eine Blazor Web App mit dem interaktiven Rendermodus „Auto“ (Server und WebAssembly) und einem Interaktivitätsspeicherort pro Komponente erstellt haben.

  1. Öffnen Sie die App.
  2. Legen Sie einen Haltepunkt in der Zeile currentCount++; in der Counter-Komponente (Pages/Counter.razor) des Clientprojekts (.Client) fest.
  3. Wenn das Serverprojekt in Projektmappen-Explorer ausgewählt ist, drücken Sie F5, um die App im Debugger auszuführen.
  4. Navigieren Sie im Browser zur Counter-Seite unter /counter. Warten Sie einige Sekunden, bis der Debugproxy geladen und ausgeführt wird. Wählen Sie die Schaltfläche Klick mich aus, um auf den Haltepunkt zu gelangen.
  5. Sehen Sie sich in Visual Studio den Wert des currentCount-Felds im Fenster Lokale Variablen an.
  6. Drücken Sie F5, um die Ausführung fortzusetzen.

Haltepunkte können auch im Serverprojekt in statisch gerenderten und interaktiv gerenderten serverseitigen Komponenten getroffen werden.

  1. Beenden Sie den Debugger.
  2. Öffnen Sie in der Server-App die statisch gerenderte Weather Komponente (Components/Pages/Weather.razor) und legen Sie einen Haltepunkt an einer beliebigen Stelle in der OnInitializedAsync Methode fest.
  3. Drücken Sie F5, um die App im Debugger auszuführen.
  4. Navigieren Sie im Browser zur Weather-Seite unter /weather. Warten Sie einige Sekunden, bis der Debugproxy geladen und ausgeführt wird. Die Anwendungsausführung wird am Haltepunkt beendet.
  5. Drücken Sie F5, um die Ausführung fortzusetzen.

Während App-Starts werden Breakpoints nicht erreicht, während der Debugproxy ausgeführt wird. Dazu gehören Breakpoints in der Program-Datei und Breakpoints in den OnInitialized{Async}-Lebenszyklusmethoden von Komponenten, die von der ersten von der App angeforderten Seite geladen werden.

Debuggen einer Blazor Server-App in einer IDE

  1. Öffnen Sie die App.
  2. Legen Sie in der currentCount++;-Zeile in der Counter-Komponente (Pages/Counter.razor) einen Haltepunkt fest.
  3. Drücken Sie F5, um die App im Debugger auszuführen.
  4. Navigieren Sie im Browser zur Counter-Seite unter /counter. Warten Sie einige Sekunden, bis der Debugproxy geladen und ausgeführt wird. Wählen Sie die Schaltfläche Klick mich aus, um auf den Haltepunkt zu gelangen.
  5. Sehen Sie sich in Visual Studio den Wert des currentCount-Felds im Fenster Lokale Variablen an.
  6. Drücken Sie F5, um die Ausführung fortzusetzen.

Während App-Starts werden Breakpoints nicht erreicht, während der Debugproxy ausgeführt wird. Dazu gehören Breakpoints in der Program-Datei und Breakpoints in den OnInitialized{Async}-Lebenszyklusmethoden von Komponenten, die von der ersten von der App angeforderten Seite geladen werden.

Debuggen einer Blazor WebAssembly-App in einer IDE

  1. Öffnen Sie die App.
  2. Legen Sie in der currentCount++;-Zeile in der Counter-Komponente (Pages/Counter.razor) einen Haltepunkt fest.
  3. Drücken Sie F5, um die App im Debugger auszuführen.
  4. Navigieren Sie im Browser zur Counter-Seite unter /counter. Warten Sie einige Sekunden, bis der Debugproxy geladen und ausgeführt wird. Wählen Sie die Schaltfläche Klick mich aus, um auf den Haltepunkt zu gelangen.
  5. Sehen Sie sich in Visual Studio den Wert des currentCount-Felds im Fenster Lokale Variablen an.
  6. Drücken Sie F5, um die Ausführung fortzusetzen.

Während App-Starts werden Breakpoints nicht erreicht, während der Debugproxy ausgeführt wird. Dazu gehören Breakpoints in der Program-Datei und Breakpoints in den OnInitialized{Async}-Lebenszyklusmethoden von Komponenten, die von der ersten von der App angeforderten Seite geladen werden.

Debuggen einer gehosteten Blazor WebAssembly-App in einer IDE

  1. Wenn das Server-Projekt im Projektmappen-Explorer ausgewählt ist, drücken Sie F5, um die App im Debugger auszuführen.

    Beim Debuggen mit einem Chromium-basierten Browser wie Google Chrome oder Microsoft Edge wird möglicherweise ein neues Browserfenster mit einem separaten Profil für die Debugsitzung geöffnet, anstatt eine Registerkarte in einem vorhandenen Browserfenster mit dem Profil des Benutzers zu öffnen. Wenn das Debuggen mit dem Benutzerprofil eine Anforderung ist, verwenden Sie einen der folgenden Ansätze:

  2. Legen Sie im Client-Projekt einen Haltepunkt in der Zeile currentCount++; in der Counter-Komponente (Pages/Counter.razor) fest.

  3. Navigieren Sie im Browser zur Counter-Seite unter /counter. Warten Sie einige Sekunden, bis der Debugproxy geladen und ausgeführt wird. Wählen Sie die Schaltfläche Klick mich aus, um auf den Haltepunkt zu gelangen.

  4. Sehen Sie sich in Visual Studio den Wert des currentCount-Felds im Fenster Lokale Variablen an.

  5. Drücken Sie F5, um die Ausführung fortzusetzen.

Sie können auch Servercode im Server-Projekt debuggen:

  1. Legen Sie einen Breakpoint auf der Seite Pages/FetchData.razor inOnInitializedAsync fest.
  2. Legen Sie einen Breakpoint in der Aktionsmethode Get in WeatherForecastController fest.
  3. Rufen Sie die Fetch Data-Seite auf, damit der Code in der FetchData-Komponente bis zum ersten Breakpoint ausgeführt wird, bevor eine HTTP-Anforderung für den Server ausgegeben wird.
  4. Drücken Sie F5, damit die Ausführung bis zum Breakpoint für den Server in WeatherForecastController ausgeführt wird.
  5. Drücken Sie wieder F5, um die Ausführung fortzusetzen, damit die WeatherForecast-Tabelle im Browser gerendert wird.

Während App-Starts werden Breakpoints nicht erreicht, während der Debugproxy ausgeführt wird. Dazu gehören Breakpoints in der Program-Datei und Breakpoints in den OnInitialized{Async}-Lebenszyklusmethoden von Komponenten, die von der ersten von der App angeforderten Seite geladen werden.

Ohne Debuggen starten [STRG+F5 (Windows) oder +F5 (macOS)] wird nicht unterstützt. Wenn die App in der Debugkonfiguration ausgeführt wird, führt der Debugmehraufwand immer zu einer geringen Leistungsminderung.

Anfügen an eine vorhandene Visual Studio Code-Debugsitzung

Um an eine laufende Blazor-App anzufügen, öffnen Sie die .vscode/launch.json-Datei, und ersetzen Sie den {URL}-Platzhalter durch die URL, unter der die App ausgeführt wird:

{
  "name": "Attach and Debug",
  "type": "blazorwasm",
  "request": "attach",
  "url": "{URL}"
}

Startoptionen für Visual Studio Code

Die Startkonfigurationsoptionen in der folgenden Tabelle werden für den blazorwasm-Debugtyp (.vscode/launch.json) unterstützt.

Option Beschreibung
browser Der Browser, der für die Debugsitzung gestartet werden muss. Wird auf edge oder chrome festgelegt. Wird standardmäßig auf edge festgelegt.
cwd Das Arbeitsverzeichnis, unter dem die App gestartet werden soll.
request Verwenden Sie launch, um eine Debugsitzung zu starten und einer Blazor WebAssembly-App anzufügen oder attach, um eine Debugsitzung einer bereits laufenden App anzufügen.
timeout Die Anzahl der Millisekunden, die auf das Anfügen der Debugsitzung gewartet werden soll. Wird standardmäßig auf 30.000 Millisekunden (30 Sekunden) festgelegt.
trace Wird zum Generieren von Protokollen vom JS-Debugger verwendet. Zum Generieren von Protokollen auf true festlegen.
url Die URL, die beim Debuggen im Browser geöffnet werden soll.
webRoot Gibt den absoluten Pfad des Webservers an. Muss gesetzt werden, wenn eine App von einer Unterroute bereitgestellt wird.

Die zusätzlichen Optionen in der folgenden Tabelle gelten nur für gehostete Blazor WebAssembly-Apps.

Option Beschreibung
env Die Umgebungsvariable, die für den gestarteten Prozess bereitgestellt werden muss. Trifft nur zu, wenn hosted auf true festgelegt ist.
hosted Muss auf true gesetzt werden, wenn eine gehostete Blazor WebAssembly-App gestartet und debuggt werden soll.
program Ein Verweis auf die ausführbare Datei zur Ausführung des Servers der gehosteten App. Muss festgelegt werden, wenn hosted den Wert true hat.

Debuggen Sie Blazor WebAssembly mit Google Chrome oder Microsoft Edge

Die Anleitung in diesem Abschnitt wendet Debugging von Blazor WebAssembly-Apps in an:

  • Google Chrome unter Windows oder macOS.
  • *Microsoft Edge, das unter Windows ausgeführt wird.
  1. Führen Sie die App in einer Befehlsshell mit dotnet watch (oder dotnet run) aus.

  2. Starten Sie einen Browser, und navigieren Sie zur URL der App.

  3. Starten Sie das Remotedebugging, indem Sie Folgendes drücken:

    • UMSCHALT+ALT+D unter Windows.
    • UMSCHALT++D unter macOS.

    Der Browser muss mit aktiviertem Remotedebuggen ausgeführt werden, was nicht das Standardverhalten ist. Wenn das Remotedebuggen deaktiviert ist, wird eine Seite mit der Meldung Debugfähige Browserregisterkarte nicht gefunden gerendert, die Anweisungen zum Starten des Browsers mit geöffnetem Debuggingport enthält. Folgen Sie den Anweisungen für Ihren Browser.

    Nachdem Sie die Anweisungen zum Aktivieren des Remotedebuggens ausgeführt haben, wird die App in einem neuen Browserfenster geöffnet. Starten Sie das Remotedebuggen, indem Sie die HotKey-Kombination im neuen Browserfenster drücken:

    • UMSCHALT+ALT+D unter Windows.
    • UMSCHALT++D unter macOS.

    Eine neue Browserregisterkarte für Fensterentwicklertools wird geöffnet, die ein Ghosted Image der App anzeigt.

    Hinweis

    Wenn Sie die Anweisungen zum Öffnen einer neuen Browserregisterkarte mit aktiviertem Remotedebuggen befolgt haben, können Sie das ursprüngliche Browserfenster schließen und das zweite Fenster geöffnet lassen, wobei die erste Registerkarte die App ausführt und die zweite Registerkarte den Debugger.

  4. Nach einem kurzen Moment zeigt die Registerkarte Quellen eine Liste der .NET-Assemblys und -Seiten der App an.

  5. Öffnen Sie den Knoten file://. In Komponentencode- (.razor Dateien) und C#-Codedateien (.cs), werden von Ihnen festgelegte Breakpoints getroffen, wenn Code auf der Browserregisterkarte der App ausgeführt wird (die erste Registerkarte, die nach dem Starten des Remotedebuggens geöffnet wurde). Nachdem ein Breakpoint erreicht wurde, durchlaufen Sie den Code in Einzelschritten (F10) oder setzen Sie die Codeausführung normal in der Registerkarte „Debuggen“ fort (F8).

Für das Chromium-basierte Browserdebugging stellt Blazor einen Debugproxy bereit, der das Chrome DevTools-Protokoll implementiert und das Protokoll mit .NET-spezifischen Informationen erweitert. Wenn die Tastenkombination zum Debuggen gedrückt wird, verweist Blazor die Chrome DevTools auf den Proxy. Der Proxy stellt eine Verbindung mit dem Browserfenster her, das Sie debuggen möchten (daher die Notwendigkeit, das Remotedebuggen zu aktivieren).

Debuggen einer Blazor WebAssembly-App mit Firefox

Die Anleitung in diesem Abschnitt bezieht sich auf Debugging von Blazor WebAssembly-Apps in Firefox, die unter Windows ausgeführt werden.

Zum Debuggen einer Blazor WebAssembly-App mit Firefox muss der Browser für das Remotedebuggen konfiguriert sein und eine Verbindung mit dem Browser mithilfe der Browserentwicklertools über den .NET-WebAssembly-Debugproxy hergestellt werden.

Hinweis

Das Debuggen in Firefox über Visual Studio wird derzeit nicht unterstützt.

So debuggen Sie eine Blazor WebAssembly-App in Firefox während der Entwicklung

  1. Firefox konfigurieren:
    • Öffnen Sie about:config in einer neuen Browserregisterkarte. Lesen und Schließen der angezeigten Warnung.
    • Aktivieren Sie devtools.debugger.remote-enabled, indem Sie den Wert auf True festlegen.
    • Aktivieren Sie devtools.chrome.enabled, indem Sie den Wert auf True festlegen.
    • Deaktivieren Sie devtools.debugger.prompt-connection, indem Sie den Wert auf False festlegen.
  2. Schließen Sie alle Firefox-Instanzen.
  3. Führen Sie die App in einer Befehlsshell mit dotnet watch (oder dotnet run) aus.
  4. Starten Sie den Firefox-Browser neu und navigieren Sie zur App.
  5. Öffnen Sie about:debugging in einer neuen Browserregisterkarte. Lassen Sie diese Registerkarte geöffnet.
  6. Wechseln Sie zurück zur Registerkarte, auf der die App ausgeführt wird. Starten Sie das Remotedebuggen, indem Sie UMSCHALT+ALT+D drücken.
  7. Öffnen Sie auf der Registerkarte Debugger die App-Quelldatei, die Sie debuggen möchten, unter dem Knoten file://, und legen Sie einen Breakpoint fest. Legen Sie beispielsweise in der IncrementCount-Methode der Counter-Komponente (Pages/Counter.razor) einen Haltepunkt für die currentCount++;-Zeile fest.
  8. Navigieren Sie zur Counter-Komponentenseite (/counter) auf der Browserregisterkarte der App und wählen Sie die Zählerschaltfläche aus, um auf den Haltepunkt zu gelangen.
  9. Drücken Sie F5, um die Ausführung auf der Registerkarte „Debuggen“ fortzusetzen.

Halt bei Ausnahmefehlern

Der Debugger beschädigt nicht bei unbehandelten Ausnahmen, da Blazor Ausnahmen abfängt, die vom Entwickler*in nicht behandelt werden.

So fügen Sie einen Halt bei Ausnahmefehlern ein

  • Öffnen Sie die Ausnahmeeinstellungen des Debuggers (Debuggen>Windows>Ausnahmeeinstellungen) in Visual Studio.
  • Legen Sie die folgenden Einstellungen für JavaScript-Ausnahmen fest:
    • Alle Ausnahmen
    • Nicht abgefangene Ausnahmen

Browserquellzuordnungen

Browserquellzuordnungen ermöglichen es dem Browser, kompilierte Dateien zu ihren ursprünglichen Quelldateien zurück zuzuordnen und sie werden häufig für clientseitiges Debuggen verwendet. Allerdings ordnet Blazor C# derzeit nicht direkt zu JavaScript/WASM zu. Stattdessen übernimmt Blazor die IL-Interpretation innerhalb des Browsers, sodass Quellzuordnungen nicht relevant sind.

Firewallkonfiguration

Wenn eine Firewall die Kommunikation mit dem Debugproxy blockiert, erstellen Sie eine Firewallausnahmeregel, die die Kommunikation zwischen Browser und NodeJS-Prozess zulässt.

Warnung

Änderungen an einer Firewallkonfiguration müssen umsichtig erfolgen, damit keine Sicherheitsrisiken entstehen. Setzen Sie Sicherheitsleitlinien sorgfältig um, befolgen Sie bewährte Methoden, und beachten Sie die Warnungen des Herstellers der Firewall.

Für das Zulassen einer offenen Kommunikation mit dem NodeJS-Prozess gilt Folgendes:

  • Öffnet den Node-Server für jede beliebige Verbindung abhängig von den Fähigkeiten und der Konfiguration der Firewall.
  • Kann abhängig von Ihrem Netzwerk riskant sein.
  • Wird nur auf Entwicklercomputern empfohlen.

Lassen Sie nach Möglichkeit eine offene Kommunikation mit dem NodeJS-Prozess nur in vertrauenswürdigen oder privaten Netzwerken zu.

Eine Anleitung zur Konfiguration der Windows-Firewall finden Sie unter Erstellen einer Regel für eingehende Programme oder Dienste. Weitere Informationen finden Sie unter Windows Defender-Firewall mit erweiterter Sicherheit und zugehörigen Artikeln in der Dokumentation zur Windows-Firewall.

Problembehandlung

Wenn Sie auf Fehler stoßen, könnten die folgenden Tipps helfen:

  • Haltepunkte entfernen:
    • Google Chrome: Öffnen Sie auf der Registerkarte Debugger die Entwicklertools in Ihrem Browser. Führen Sie in der Konsole localStorage.clear() aus, um alle Breakpoints zu entfernen.
    • Microsoft Edge: Öffnen Sie auf der Registerkarte Anwendung den lokalen Speicher. Klicken Sie mit der rechten Maustaste auf die Website, und wählen Sie Löschen aus.
  • Vergewissern Sie sich, dass Sie das ASP.NET Core-HTTPS-Entwicklungszertifikat installiert haben und diesem vertrauen. Weitere Informationen finden Sie unter Erzwingen von HTTPS in ASP.NET Core.
  • Visual Studio erfordert die Option JavaScript-Debugging für ASP.NET (Chrome und Edge) aktivieren-Option in Tools>Optionen>Debuggen>Allgemein. Dies ist die Standardeinstellung für Visual Studio. Wenn das Debuggen nicht funktioniert, vergewissern Sie sich, dass die Option ausgewählt ist.
  • Wenn Ihre Umgebung einen HTTP-Proxy verwendet, sorgen Sie dafür, dass localhost in den Umgehungseinstellungen des Proxys eingeschlossen ist. Dies können Sie tun, indem Sie die NO_PROXY-Umgebungsvariable an einem der beiden folgenden Orte festlegen:
    • Die launchSettings.json-Datei für das Projekt
    • Auf Ebene der Umgebungsvariablen für Benutzer oder System, damit sie auf alle Apps angewendet wird. Wenn Sie eine Umgebungsvariable verwenden, starten Sie Visual Studio neu, damit die Änderungen übernommen werden.
  • Stellen Sie sicher, dass Firewalls oder Proxys die Kommunikation mit dem Debugproxy (NodeJS-Prozess) nicht blockieren. Weitere Informationen finden Sie im Abschnitt Firewallkonfiguration.

In OnInitialized{Async} nicht verwendete Breakpoints

Der Debugproxy des Blazor-Frameworks wird beim Starten der App nicht sofort gestartet, sodass Haltepunkte in den OnInitialized{Async} Lebenszyklusmethoden möglicherweise nicht getroffen werden. Es wird empfohlen, am Anfang des Methodentextes eine Verzögerung hinzuzufügen, um dem Debugproxy etwas Zeit zum Starten zu geben, bevor der Breakpoint erkannt wird. Sie können die Verzögerung auf Grundlage einer if-Compileranweisung einschließen, um sicherzustellen, dass die Verzögerung für einen Releasebuild der App nicht vorhanden ist.

OnInitialized:

protected override void OnInitialized()
{
#if DEBUG
    Thread.Sleep(10000);
#endif

    ...
}

OnInitializedAsync:

protected override async Task OnInitializedAsync()
{
#if DEBUG
    await Task.Delay(10000);
#endif

    ...
}

Timeout in Visual Studio (Windows)

Wenn Visual Studio eine Ausnahme auslöst, dass der Debugadapter nicht gestartet werden konnte, und meldet, dass das Timeout erreicht wurde, können Sie das Timeout mit einer Registrierungseinstellung anpassen:

VsRegEdit.exe set "<VSInstallFolder>" HKCU JSDebugger\Options\Debugging "BlazorTimeoutInMilliseconds" dword {TIMEOUT}

Der Platzhalter {TIMEOUT} im vorangehenden Befehl wird in Millisekunden angegeben. Beispielsweise wird eine Minute als 60000 zugewiesen.