Debuggen von ASP.NET Core-Apps
Hinweis
Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Warnung
Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-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.
Die aktuelle Version finden Sie in der .NET 9-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:
- Debuggen Sie in nicht lokalen Szenarien (z. B. Windows-Subsystem für Linux (WSL) oder Visual Studio Codespaces).
- Debuggen Sie in Firefox, aus Visual Studio oder Visual Studio Code.
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 denOnInitialized{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:
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.
Packages
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.Server
Verweist 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:
- Client Project:
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. - Server Projekt:
Microsoft.AspNetCore.Components.WebAssembly.Server
Verweist auf ein internes Paket (Microsoft.NETCore.BrowserDebugHost.Transport
) für Assemblys, die den Browser-Debughost teilen.
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.
- Öffnen Sie die App.
- Legen Sie einen Haltepunkt in der Zeile
currentCount++;
in derCounter
-Komponente (Pages/Counter.razor
) des Clientprojekts (.Client
) fest. - Wenn das Serverprojekt in Projektmappen-Explorer ausgewählt ist, drücken Sie F5, um die App im Debugger auszuführen.
- 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. - Sehen Sie sich in Visual Studio den Wert des
currentCount
-Felds im Fenster Lokale Variablen an. - 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.
- Beenden Sie den Debugger.
- Ö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 derOnInitializedAsync
Methode fest. - Drücken Sie F5, um die App im Debugger auszuführen.
- 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. - 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
- Öffnen Sie die App.
- Legen Sie in der
currentCount++;
-Zeile in derCounter
-Komponente (Pages/Counter.razor
) einen Haltepunkt fest. - Drücken Sie F5, um die App im Debugger auszuführen.
- 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. - Sehen Sie sich in Visual Studio den Wert des
currentCount
-Felds im Fenster Lokale Variablen an. - 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
- Öffnen Sie die App.
- Legen Sie in der
currentCount++;
-Zeile in derCounter
-Komponente (Pages/Counter.razor
) einen Haltepunkt fest. - Drücken Sie F5, um die App im Debugger auszuführen.
- 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. - Sehen Sie sich in Visual Studio den Wert des
currentCount
-Felds im Fenster Lokale Variablen an. - 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
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:
- Schließen Sie alle geöffneten Browserinstanzen, bevor Sie F5 drücken, um das Debuggen zu starten.
- Konfigurieren Sie Visual Studio, um den Browser mit dem Profil des Benutzers zu starten. Weitere Informationen zu diesem Ansatz finden Sie unter BlazorWASM-Debuggen in VS startet Edge mit einem separaten Benutzerdatenverzeichnis (dotnet/aspnetcore #20915).
Legen Sie im Client-Projekt einen Haltepunkt in der Zeile
currentCount++;
in derCounter
-Komponente (Pages/Counter.razor
) fest.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.Sehen Sie sich in Visual Studio den Wert des
currentCount
-Felds im Fenster Lokale Variablen an.Drücken Sie F5, um die Ausführung fortzusetzen.
Sie können auch Servercode im Server-Projekt debuggen:
- Legen Sie einen Breakpoint auf der Seite
Pages/FetchData.razor
inOnInitializedAsync fest. - Legen Sie einen Breakpoint in der Aktionsmethode
Get
inWeatherForecastController
fest. - Rufen Sie die
Fetch Data
-Seite auf, damit der Code in derFetchData
-Komponente bis zum ersten Breakpoint ausgeführt wird, bevor eine HTTP-Anforderung für den Server ausgegeben wird. - Drücken Sie F5, damit die Ausführung bis zum Breakpoint für den Server in
WeatherForecastController
ausgeführt wird. - 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.
Führen Sie die App in einer Befehlsshell mit
dotnet watch
(oderdotnet run
) aus.Starten Sie einen Browser, und navigieren Sie zur URL der App.
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.
Nach einem kurzen Moment zeigt die Registerkarte Quellen eine Liste der .NET-Assemblys und -Seiten der App an.
Ö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
- 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 aufTrue
festlegen. - Aktivieren Sie
devtools.chrome.enabled
, indem Sie den Wert aufTrue
festlegen. - Deaktivieren Sie
devtools.debugger.prompt-connection
, indem Sie den Wert aufFalse
festlegen.
- Öffnen Sie
- Schließen Sie alle Firefox-Instanzen.
- Führen Sie die App in einer Befehlsshell mit
dotnet watch
(oderdotnet run
) aus. - Starten Sie den Firefox-Browser neu und navigieren Sie zur App.
- Öffnen Sie
about:debugging
in einer neuen Browserregisterkarte. Lassen Sie diese Registerkarte geöffnet. - Wechseln Sie zurück zur Registerkarte, auf der die App ausgeführt wird. Starten Sie das Remotedebuggen, indem Sie UMSCHALT+ALT+D drücken.
- Öffnen Sie auf der Registerkarte
Debugger
die App-Quelldatei, die Sie debuggen möchten, unter dem Knotenfile://
, und legen Sie einen Breakpoint fest. Legen Sie beispielsweise in derIncrementCount
-Methode derCounter
-Komponente (Pages/Counter.razor
) einen Haltepunkt für diecurrentCount++;
-Zeile fest. - 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. - 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.
- Google Chrome: Öffnen Sie auf der Registerkarte Debugger die Entwicklertools in Ihrem Browser. Führen Sie in der Konsole
- 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 dieNO_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.
- Die
- 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.
protected override void OnInitialized()
{
#if DEBUG
Thread.Sleep(10000);
#endif
...
}
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.