Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga
Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z aktualną wersją, zobacz artykuł w wersji .NET 10.
Ostrzeżenie
Ta wersja ASP.NET Core nie jest już obsługiwana. Aby uzyskać więcej informacji, zobacz zasady pomocy technicznej platformy .NET i platformy .NET Core. Aby zapoznać się z aktualną wersją, zobacz artykuł w wersji .NET 10.
W tym artykule opisano sposób debugowania Blazor aplikacji, w tym debugowania Blazor WebAssembly aplikacji za pomocą narzędzi deweloperskich przeglądarki lub zintegrowanego środowiska projektowego (IDE).
Blazor Web Apps można debugować w programie Visual Studio lub Visual Studio Code.
Blazor WebAssembly aplikacje można debugować:
- W programie Visual Studio lub Visual Studio Code.
- Korzystanie z narzędzi programistycznych przeglądarki w przeglądarkach opartych na Chromium, w tym Przeglądarki Microsoft Edge, Google Chrome i Firefox.
Dostępne scenariusze debugowania Blazor WebAssembly obejmują:
- Ustaw i usuń punkty przerwania.
- Uruchom aplikację z obsługą debugowania w środowiskach IDE.
- Wykonuj kod krok po kroku.
- Wznów wykonywanie kodu za pomocą skrótu klawiaturowego w środowiskach IDE.
- W oknie Ustawienia lokalne obserwuj wartości zmiennych lokalnych.
- Zobacz stos wywołań, w tym łańcuchy wywołań między językiem JavaScript i platformą .NET.
- Użyj serwera symboli do debugowania skonfigurowanego przez preferencje programu Visual Studio.
Nieobsługiwane scenariusze obejmują:
- Debugowanie w scenariuszach innych niż lokalne (na przykład Podsystem Windows dla systemu Linux (WSL) lub Visual Studio Codespaces.
- Debuguj w przeglądarce Firefox z poziomu programu Visual Studio lub Visual Studio Code.
Blazor Server aplikacje można debugować w programie Visual Studio lub Visual Studio Code.
Blazor WebAssembly aplikacje można debugować:
- W programie Visual Studio lub Visual Studio Code.
- Korzystanie z narzędzi deweloperskich w przeglądarkach opartych na Chromium, w tym Microsoft Edge i Google Chrome.
Nieobsługiwane scenariusze aplikacji Blazor WebAssembly obejmują:
- Ustaw i usuń punkty przerwania.
- Uruchom aplikację z obsługą debugowania w środowiskach IDE.
- Wykonuj kod krok po kroku.
- Wznów wykonywanie kodu za pomocą skrótu klawiaturowego w środowiskach IDE.
- W oknie Ustawienia lokalne obserwuj wartości zmiennych lokalnych.
- Zobacz stos wywołań, w tym łańcuchy wywołań między językiem JavaScript i platformą .NET.
- Debugowanie w scenariuszach innych niż lokalne (na przykład Podsystem Windows dla systemu Linux (WSL) lub Visual Studio Codespaces.
- Użyj serwera symboli do debugowania.
Blazor Server aplikacje można debugować w programie Visual Studio lub Visual Studio Code.
Blazor WebAssembly aplikacje można debugować:
- W programie Visual Studio lub Visual Studio Code.
- Korzystanie z narzędzi deweloperskich w przeglądarkach opartych na Chromium, w tym Microsoft Edge i Google Chrome.
Nieobsługiwane scenariusze aplikacji Blazor WebAssembly obejmują:
- Ustaw i usuń punkty przerwania.
- Uruchom aplikację z obsługą debugowania w środowiskach IDE.
- Wykonuj kod krok po kroku.
- Wznów wykonywanie kodu za pomocą skrótu klawiaturowego w środowiskach IDE.
- W oknie Ustawienia lokalne obserwuj wartości zmiennych lokalnych.
- Zobacz stos wywołań, w tym łańcuchy wywołań między językiem JavaScript i platformą .NET.
- Naciśnij punkty przerwania podczas uruchamiania aplikacji przed uruchomieniem serwera proxy debugowania. Obejmuje to punkty przerwania w pliku
Programoraz punkty przerwania w metodachOnInitialized{Async}cyklu życia komponentów ładowanych przez pierwszą stronę żądaną z aplikacji. - Debugowanie w scenariuszach innych niż lokalne (na przykład Podsystem Windows dla systemu Linux (WSL) lub Visual Studio Codespaces.
- Użyj serwera symboli do debugowania.
Blazor WebAssembly Brama
Microsoft.AspNetCore.Components.Gateway jest lekkim hostem ASP.NET Core obsługującym autonomiczne aplikacje Blazor WebAssembly podczas programowania i produkcji.
Gateway jest w pełni funkcjonalnym hostem ASP.NET Core, a nie tylko narzędziem deweloperskim do plików statycznych, więc autonomiczne aplikacje Blazor WebAssembly oferują:
- Wbudowany mechanizm routingu zastępczego SPA: żądania, które nie pasują do żadnego zasobu statycznego, są kierowane do
index.html, dzięki czemu trasy po stronie klienta, takie jak/orders/42, działają przy odświeżeniu przeglądarki i bezpośredniej nawigacji bez potrzeby tworzenia niestandardowego elementu docelowego MSBuild. - Wielu klientów Blazor WebAssembly na jednym hoście: pojedyncza instancja Gateway może obsługiwać więcej niż jednego klienta Blazor WebAssembly pod różnymi prefiksami ścieżek, konfigurowanymi w sekcji
ClientApps. Jest to punkt integracji, którego platforma .NET Aspire używa do obsługi klientów Blazor WebAssembly wraz z usługami backendowymi w ramach jednego uruchomienia AppHost. - Wbudowana infrastruktura odwrotnego serwera proxy YARP: YARP jest dostarczany z bramą i stanowi podstawę przekazywania ruchu do usług zaplecza wraz z klientem WebAssembly, umożliwiając obsługę Aspire scenariuszy z wieloma klientami.
Aby użyć składnika Gateway w istniejącej samodzielnej aplikacji Blazor WebAssembly, przeznaczonej dla platformy .NET 11 lub nowszej, dodaj odwołanie do pakietu Microsoft.AspNetCore.Components.Gateway w pliku projektu aplikacji.
Uwaga
Aby uzyskać instrukcje dodawania pakietów do aplikacji .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w temacie Przepływ pracy użycia pakietów (dokumentacja programu NuGet). Sprawdź prawidłowe wersje pakietów pod adresem NuGet.org.
Niestandardowy kod routingu i oprogramowanie pośredniczące nie są wymagane przez aplikację. Zapasowe punkty końcowe pochodzą z manifestu statycznych zasobów internetowych, który zestaw SDK generuje, gdy właściwość StaticWebAssetSpaFallbackEnabled jest ustawiona w pliku projektu aplikacji; ta właściwość jest domyślnie obecna w autonomicznych aplikacjach Blazor WebAssembly utworzonych na podstawie szablonu projektu:
<StaticWebAssetSpaFallbackEnabled>true</StaticWebAssetSpaFallbackEnabled>
Wymagania wstępne
W tej sekcji opisano wymagania wstępne dotyczące debugowania.
Wymagania wstępne dotyczące przeglądarki
Najnowsza wersja następujących przeglądarek:
- Google Chrome
- Microsoft Edge
- Firefox (tylko narzędzia deweloperskie przeglądarki)
Debugowanie wymaga najnowszej wersji następujących przeglądarek:
- Google Chrome (ustawienie domyślne)
- Microsoft Edge
Upewnij się, że zapory lub serwery proxy nie blokują komunikacji z serwerem proxy debugowania (NodeJS proces). Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja zapory.
Uwaga
Przeglądarka Apple Safari w systemie macOS nie jest obecnie obsługiwana.
Wymagania wstępne dotyczące środowiska IDE
Wymagana jest najnowsza wersja programu Visual Studio lub Visual Studio Code.
Wymagania wstępne programu Visual Studio Code
Program Visual Studio Code wymaga zestawu Deweloperskiego języka C# dla programu Visual Studio Code (Wprowadzenie do języka C# w programie VS Code). W witrynie Marketplace rozszerzeń programu Visual Studio Code przefiltruj listę rozszerzeń za pomocą ciągu "c# dev kit", aby zlokalizować rozszerzenie:
Zainstalowanie zestawu deweloperskiego języka C# powoduje automatyczne zainstalowanie następujących dodatkowych rozszerzeń:
Jeśli wystąpią ostrzeżenia lub błędy, możesz otworzyć problem (microsoft/vscode-dotnettools repozytorium GitHub) opisujący problem.
Wymagania wstępne dotyczące konfiguracji aplikacji
Wskazówki zawarte w tej podsekcji dotyczą debugowania po stronie klienta.
Properties/launchSettings.json Otwórz plik projektu startowego. Potwierdź obecność następującej inspectUri właściwości w każdym profilu uruchamiania węzła profiles pliku. Jeśli następująca właściwość nie jest obecna, dodaj ją do każdego profilu:
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
Właściwość inspectUri :
- Umożliwia środowisku IDE wykrywanie, że aplikacja jest aplikacją Blazor .
- Poleca infrastrukturze debugowania skryptów połączenie z przeglądarką przez serwer proxy debugowania Blazor.
Wartości zastępcze dla protokołu WebSocket (wsProtocol), hosta (url.hostname), portu (url.port) oraz adresu URI inspektora w uruchomionej przeglądarce (browserInspectUri) są udostępniane przez framework.
Uwaga
Gdy aplikacja jest uruchamiana za pomocą interfejsu wiersza polecenia platformy .NET, domyślnie używany jest pierwszy profil uruchamiania w launchSettings.json, którego commandName ma wartość Project. Aby użyć innego profilu (na przykład https), podaj opcję -lp|--launch-profile do dotnet watch lub dotnet run, albo przenieś preferowany profil na początek pliku.
Pakiety
Blazor Web Apps: : Microsoft.AspNetCore.Components.WebAssembly.Serverodwołuje się do pakietu wewnętrznego (Microsoft.NETCore.BrowserDebugHost.Transport) dla zestawów, które współużytkuje hosta debugowania przeglądarki.
Blazor Server: Microsoft.AspNetCore.Components.WebAssembly.Serverodwołuje się do pakietu wewnętrznego (Microsoft.NETCore.BrowserDebugHost.Transport) dla zestawów, które współużytkuje hosta debugowania przeglądarki.
Autonomiczna Blazor WebAssembly: Microsoft.AspNetCore.Components.Gateway: lekki host ASP.NET Core obsługujący autonomiczne aplikacje Blazor WebAssembly podczas programowania i produkcji.
Samodzielny Blazor WebAssembly: Microsoft.AspNetCore.Components.WebAssembly.DevServer: serwer deweloperski używany podczas tworzenia aplikacji Blazor WebAssembly. Wewnętrznie wywołuje UseWebAssemblyDebugging, aby dodać pośrednik do debugowania aplikacji Blazor WebAssembly w narzędziach deweloperskich Chromium.
Hostowane Blazor WebAssembly:
-
Client project:
Microsoft.AspNetCore.Components.WebAssembly.DevServer: Serwer deweloperski używany podczas tworzenia aplikacji Blazor. Wewnętrznie wywołuje UseWebAssemblyDebugging, aby dodać pośrednik do debugowania aplikacji Blazor WebAssembly w narzędziach deweloperskich Chromium. -
Server project: :
Microsoft.AspNetCore.Components.WebAssembly.Serverodwołuje się do pakietu wewnętrznego (Microsoft.NETCore.BrowserDebugHost.Transport) dla zestawów, które współużytkuje hosta debugowania przeglądarki.
Uwaga
Aby uzyskać instrukcje dodawania pakietów do aplikacji .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w temacie Przepływ pracy użycia pakietów (dokumentacja programu NuGet). Sprawdź prawidłowe wersje pakietów pod adresem NuGet.org.
Debugowanie elementu Blazor Web App w środowisku IDE
W przykładzie w tej sekcji założono, że utworzono obiekt Blazor Web App z interaktywnym trybem renderowania Auto (Server i WebAssembly) oraz lokalizacją interaktywności dla poszczególnych składników.
- Otwórz aplikację.
- Ustaw punkt przerwania w wierszu
currentCount++;w komponencieCounter(Pages/Counter.razor) projektu klienta (.Client). - Po wybraniu projektu serwera w Eksplorator rozwiązań naciśnij F5, aby uruchomić aplikację w debugerze.
- W przeglądarce przejdź do strony
Counterpod adresem/counter. Poczekaj kilka sekund, aż proxy debugowania się załaduje i uruchomi. Kliknij przycisk Kliknij mnie, aby osiągnąć punkt przerwania. - W programie Visual Studio sprawdź wartość
currentCountpola w oknie Ustawienia lokalne . - Naciśnij F5 , aby kontynuować wykonywanie.
Punkty przerwania mogą być również osiągane w projekcie serwera w komponentach po stronie serwera renderowanych statycznie i renderowanych interaktywnie.
- Zatrzymaj debuger.
- W aplikacji serwerowej otwórz komponent
Weatherrenderowany statycznie (Components/Pages/Weather.razor) i ustaw punkt przerwania w dowolnym miejscu metodyOnInitializedAsync. - Naciśnij F5 , aby uruchomić aplikację w debugerze.
- W przeglądarce przejdź na stronę
Weatherpod adresem/weather. Poczekaj kilka sekund, aż proxy debugowania się załaduje i uruchomi. Wykonywanie aplikacji zatrzymuje się w punkcie przerwania. - Naciśnij F5 , aby kontynuować wykonywanie.
Punkty przerwania nie są osiągane podczas uruchamiania aplikacji przed uruchomieniem serwera proxy debugowania. Obejmuje to punkty przerwania w pliku Program oraz punkty przerwania w metodach OnInitialized{Async} cyklu życia komponentów ładowanych przez pierwszą stronę żądaną z aplikacji.
Debuguj aplikację Blazor Server w środowisku IDE
- Otwórz aplikację.
- Ustaw punkt przerwania w wierszu
currentCount++;w komponencieCounter(Pages/Counter.razor). - Naciśnij F5 , aby uruchomić aplikację w debugerze.
- W przeglądarce przejdź do strony
Counterpod adresem/counter. Poczekaj kilka sekund, aż proxy debugowania się załaduje i uruchomi. Kliknij przycisk Kliknij mnie, aby osiągnąć punkt przerwania. - W programie Visual Studio sprawdź wartość
currentCountpola w oknie Ustawienia lokalne . - Naciśnij F5 , aby kontynuować wykonywanie.
Punkty przerwania nie są osiągane podczas uruchamiania aplikacji przed uruchomieniem serwera proxy debugowania. Obejmuje to punkty przerwania w pliku Program oraz punkty przerwania w metodach OnInitialized{Async} cyklu życia komponentów ładowanych przez pierwszą stronę żądaną z aplikacji.
Debuguj aplikację Blazor WebAssembly w środowisku IDE
- Otwórz aplikację.
- Ustaw punkt przerwania w wierszu
currentCount++;w komponencieCounter(Pages/Counter.razor). - Naciśnij F5 , aby uruchomić aplikację w debugerze.
- W przeglądarce przejdź do strony
Counterpod adresem/counter. Poczekaj kilka sekund, aż proxy debugowania się załaduje i uruchomi. Kliknij przycisk Kliknij mnie, aby osiągnąć punkt przerwania. - W programie Visual Studio sprawdź wartość
currentCountpola w oknie Ustawienia lokalne . - Naciśnij F5 , aby kontynuować wykonywanie.
Punkty przerwania nie są osiągane podczas uruchamiania aplikacji przed uruchomieniem serwera proxy debugowania. Obejmuje to punkty przerwania w pliku Program oraz punkty przerwania w metodach OnInitialized{Async} cyklu życia komponentów ładowanych przez pierwszą stronę żądaną z aplikacji.
Debugowanie hostowanej Blazor WebAssembly aplikacji w środowisku IDE
Po wybraniu Server projektu w Eksplorator rozwiązań naciśnij F5, aby uruchomić aplikację w debugerze.
Podczas debugowania przy użyciu przeglądarki opartej na chromium, takiej jak Google Chrome lub Microsoft Edge, nowe okno przeglądarki może zostać otwarte z oddzielnym profilem sesji debugowania zamiast otwierania karty w istniejącym oknie przeglądarki z profilem użytkownika. Jeśli debugowanie przy użyciu profilu użytkownika jest wymagane, zastosuj jedną z następujących metod:
- Zamknij wszystkie otwarte wystąpienia przeglądarki przed naciśnięciem F5 , aby rozpocząć debugowanie.
- Skonfiguruj program Visual Studio, aby uruchomić przeglądarkę przy użyciu profilu użytkownika. Aby uzyskać więcej informacji na temat tego podejścia, zobacz Blazor Debugowanie WASM w programie VS uruchamia przeglądarkę Edge z oddzielnym katalogiem danych użytkownika (dotnet/aspnetcore #20915).
W projekcie Client ustaw punkt przerwania w wierszu
currentCount++;w komponencieCounter(Pages/Counter.razor).W przeglądarce przejdź do strony
Counterpod adresem/counter. Poczekaj kilka sekund, aż proxy debugowania się załaduje i uruchomi. Kliknij przycisk Kliknij mnie, aby osiągnąć punkt przerwania.W programie Visual Studio sprawdź wartość
currentCountpola w oknie Ustawienia lokalne .Naciśnij F5 , aby kontynuować wykonywanie.
Możesz również debugować kod serwera w projekcie Server :
- Ustaw punkt przerwania na stronie
Pages/FetchData.razorw OnInitializedAsync. - Ustaw punkt przerwania w
WeatherForecastControllermetodzieGetakcji . - Przejdź do strony
Fetch Data, aby zatrzymać się na pierwszym punkcie przerwania w komponencieFetchDatatuż przed wysłaniem żądania HTTP do serwera. - Naciśnij F5, aby wznowić wykonywanie, a następnie osiągnąć punkt przerwania na serwerze w
WeatherForecastController. - Naciśnij F5 ponownie, aby umożliwić kontynuowanie wykonywania i wyświetlenie tabeli prognozy pogody renderowanej w przeglądarce.
Punkty przerwania nie są osiągane podczas uruchamiania aplikacji przed uruchomieniem serwera proxy debugowania. Obejmuje to punkty przerwania w pliku Program oraz punkty przerwania w metodach OnInitialized{Async} cyklu życia komponentów ładowanych przez pierwszą stronę żądaną z aplikacji.
Dołączanie do istniejącej sesji debugowania programu Visual Studio Code
Aby połączyć się z uruchomioną aplikacją Blazor, otwórz plik .vscode/launch.json i zastąp symbol zastępczy {URL} adresem URL, pod którym działa aplikacja:
{
"name": "Attach and Debug",
"type": "blazorwasm",
"request": "attach",
"url": "{URL}"
}
Opcje uruchamiania programu Visual Studio Code
Opcje konfiguracji uruchamiania przedstawione w poniższej tabeli są obsługiwane w przypadku typu debugowania blazorwasm (.vscode/launch.json).
| Opcja | Opis |
|---|---|
browser |
Przeglądarka do uruchomienia na potrzeby sesji debugowania. Ustaw edge lub chrome. Wartość domyślna to edge. |
cwd |
Katalog roboczy, w którym uruchamiana jest aplikacja. |
request |
Służy launch do uruchamiania i dołączania sesji debugowania do Blazor WebAssembly aplikacji lub attach dołączania sesji debugowania do już uruchomionej aplikacji. |
timeout |
Liczba milisekund oczekiwania na dołączenie sesji debugowania. Wartość domyślna to 30 000 milisekund (30 sekund). |
trace |
Służy do generowania dzienników z debugera JS. Ustaw na true, aby generować dzienniki. |
url |
Adres URL do otwarcia w przeglądarce podczas debugowania. |
webRoot |
Określa ścieżkę bezwzględną serwera internetowego. Należy ustawić, jeśli aplikacja jest udostępniana pod podścieżką. |
Dodatkowe opcje w poniższej tabeli mają zastosowanie wyłącznie do aplikacji hostowanychBlazor WebAssembly.
| Opcja | Opis |
|---|---|
env |
Zmienne środowiskowe, które mają być dostępne dla uruchomionego procesu. Ma zastosowanie tylko, jeśli hosted jest ustawione na true. |
hosted |
Musi być ustawione na true, jeśli uruchamiasz i debugujesz hostowaną aplikację Blazor WebAssembly. |
program |
Odwołanie do pliku wykonywalnego w celu uruchomienia serwera hostowanej aplikacji. Należy ustawić wartość , jeśli hosted ma wartość true. |
Debugowanie Blazor WebAssembly za pomocą przeglądarki Google Chrome lub Przeglądarki Microsoft Edge
Wskazówki w tej sekcji dotyczą debugowania aplikacji Blazor WebAssembly w:
- Przeglądarka Google Chromeuruchomiona w systemie Windows lub macOS.
- przeglądarki Microsoft Edge działającej w systemie Windows.
Uruchom aplikację w wierszu polecenia za pomocą polecenia
dotnet watch(lubdotnet run).Uruchom przeglądarkę i przejdź do adresu URL aplikacji.
Rozpocznij debugowanie zdalne, naciskając:
- Shift+Alt+d w systemie Windows.
- Shift+⌘+d w systemie macOS.
Przeglądarka musi być uruchomiona z włączonym debugowaniem zdalnym, co nie jest domyślne. Jeśli debugowanie zdalne jest wyłączone, zostanie wyświetlona strona błędu Nie można znaleźć karty przeglądarki do debugowania z instrukcjami, jak uruchomić przeglądarkę z otwartym portem debugowania. Postępuj zgodnie z instrukcjami przeglądarki.
Po wykonaniu instrukcji umożliwiających zdalne debugowanie aplikacja zostanie otwarta w nowym oknie przeglądarki. Rozpocznij debugowanie zdalne, naciskając kombinację HotKey w nowym oknie przeglądarki:
- Shift+Alt+d w systemie Windows.
- Shift+⌘+d w systemie macOS.
Otworzy się nowa karta przeglądarki z narzędziami deweloperskimi, pokazująca wyszarzony obraz aplikacji.
Uwaga
Jeśli wykonano instrukcje otwierania nowej karty przeglądarki z włączonym debugowaniem zdalnym, możesz zamknąć oryginalne okno przeglądarki, pozostawiając drugie okno otwarte przy użyciu pierwszej karty z uruchomioną aplikacją i drugą kartą z uruchomionym debugerem.
Po chwili na karcie Źródła zostanie wyświetlona lista zestawów i stron platformy .NET aplikacji.
file://Otwórz węzeł. W kodzie składników (plikach.razor) i plikach kodu C# (.cs) następuje zatrzymanie na ustawionych punktach przerwania podczas wykonywania kodu na karcie przeglądarki aplikacji (karcie początkowo otwartej po rozpoczęciu debugowania zdalnego). Po zatrzymaniu na punkcie przerwania przechodź przez kod krok po kroku (F10) lub wznów normalne wykonywanie kodu (F8) na karcie debugowania.
W przypadku debugowania przeglądarek opartych na Chromium Blazor udostępnia serwer proxy debugowania, który implementuje protokół Chrome DevTools Protocol i rozszerza go o informacje specyficzne dla platformy .NET. Po naciśnięciu skrótu klawiaturowego uruchamiającego debugowanie Blazor kieruje Chrome DevTools do serwera proxy. Serwer proxy łączy się z oknem przeglądarki, które chcesz debugować (stąd potrzeba włączenia debugowania zdalnego).
Debuguj aplikację Blazor WebAssembly w przeglądarce Firefox
Wskazówki zawarte w tej sekcji dotyczą aplikacji debugowania Blazor WebAssembly w przeglądarce Firefox działającej w systemie Windows.
Debugowanie aplikacji Blazor WebAssembly w przeglądarce Firefox wymaga skonfigurowania przeglądarki do zdalnego debugowania i nawiązania połączenia z nią przy użyciu narzędzi deweloperskich przeglądarki za pośrednictwem serwera proxy debugowania WebAssembly platformy .NET.
Uwaga
Debugowanie w programie Firefox z poziomu programu Visual Studio nie jest obecnie obsługiwane.
Aby debugować aplikację Blazor WebAssembly w przeglądarce Firefox podczas programowania:
- Skonfiguruj przeglądarkę Firefox:
- Otwórz
about:configw nowej karcie przeglądarki. Przeczytaj i odrzuć wyświetlone ostrzeżenie. - Włącz
devtools.debugger.remote-enabled, ustawiając jego wartość naTrue. - Włącz
devtools.chrome.enabled, ustawiając jego wartość naTrue. - Wyłącz
devtools.debugger.prompt-connection, ustawiając jego wartość naFalse.
- Otwórz
- Zamknij wszystkie wystąpienia przeglądarki Firefox.
- Uruchom aplikację w wierszu polecenia za pomocą polecenia
dotnet watch(lubdotnet run). - Uruchom ponownie przeglądarkę Firefox i przejdź do aplikacji.
- Otwórz
about:debuggingw nowej karcie przeglądarki. Pozostaw tę kartę otwartą. - Wróć do karty, w której jest uruchomiona aplikacja. Rozpocznij debugowanie zdalne, naciskając Shift+Alt+d.
- Na karcie
Debuggerotwórz w węźlefile://plik źródłowy aplikacji, który chcesz debugować, i ustaw punkt przerwania. Na przykład ustaw punkt przerwania w wierszucurrentCount++;w metodzieIncrementCountkomponentuCounter(Pages/Counter.razor). - Przejdź na stronę komponentu
Counter(/counter) w karcie przeglądarki aplikacji i kliknij przycisk licznika, aby wywołać punkt przerwania. - Naciśnij F5 , aby kontynuować wykonywanie na karcie debugowania.
Przerwij przy nieobsłużonych wyjątkach
Debuger nie zatrzymuje się przy nieobsłużonych wyjątkach, ponieważ Blazor przechwytuje wyjątki nieobsłużone przez kod programisty.
Aby zatrzymać się przy nieobsługiwanych wyjątkach:
- Otwórz ustawienia wyjątków debugera (Debug>Windows>Ustawienia wyjątków) w programie Visual Studio.
- Ustaw następujące ustawienia wyjątków języka JavaScript:
- Wszystkie wyjątki
- Wyjątki nieuchwycone
Mapy źródłowe przeglądarki
Mapy źródłowe przeglądarki umożliwiają przeglądarce mapowanie skompilowanych plików z powrotem na oryginalne pliki źródłowe i są często używane do debugowania po stronie klienta. Blazor Jednak obecnie nie mapuje języka C# bezpośrednio na język JavaScript/Wasm. Zamiast tego Blazor interpretuje IL w przeglądarce, więc mapy źródeł nie są istotne.
Konfiguracja zapory
Jeśli zapora blokuje komunikację z debug proxy, utwórz regułę wyjątku w zaporze, która zezwala na komunikację między przeglądarką a procesem NodeJS.
Ostrzeżenie
Modyfikację konfiguracji zapory sieciowej należy przeprowadzać ostrożnie, aby uniknąć powstania luk w zabezpieczeniach. Uważnie zastosuj wskazówki dotyczące zabezpieczeń, postępuj zgodnie z najlepszymi rozwiązaniami w zakresie zabezpieczeń i przestrzegaj ostrzeżeń wydanych przez producenta zapory.
Zezwalanie na otwartą komunikację z procesem NodeJS :
- Otwiera serwer Node dla każdego połączenia, w zależności od możliwości i konfiguracji zapory.
- Może to być ryzykowne w zależności od sieci.
- Jest zalecana tylko na maszynach deweloperskich.
Jeśli to możliwe, zezwalaj tylko na otwartą komunikację z procesem NodeJSw zaufanych lub prywatnych sieciach.
Wskazówki dotyczące konfiguracji Zapory systemu Windows można znaleźć w artykule Tworzenie reguły ruchu przychodzącego dla programu lub usługi. Aby uzyskać więcej informacji, zobacz temat Zapora systemu Windows Defender z zabezpieczeniami zaawansowanymi oraz powiązane artykuły w zestawie dokumentacji Zapory systemu Windows.
Rozwiązywanie problemów
Jeśli występują błędy, następujące porady mogą pomóc:
- Usuń punkty przerwania:
- Google Chrome: na karcie Debuger otwórz narzędzia deweloperskie w przeglądarce. W konsoli programu wykonaj polecenie
localStorage.clear(), aby usunąć wszystkie punkty przerwania. - Microsoft Edge: na karcie Aplikacja otwórz Pamięć lokalna. Kliknij prawym przyciskiem myszy witrynę i wybierz polecenie Wyczyść.
- Google Chrome: na karcie Debuger otwórz narzędzia deweloperskie w przeglądarce. W konsoli programu wykonaj polecenie
- Upewnij się, że zainstalowano i zaufano certyfikatowi programistycznego ASP.NET Core HTTPS. Aby uzyskać więcej informacji, zobacz Wymuszanie protokołu HTTPS w ASP.NET Core.
- Program Visual Studio wymaga opcji Włącz debugowanie języka JavaScript dla ASP.NET (Chrome i Edge) w obszarze Narzędzia>Opcje>Debugowanie>ogólne. Jest to ustawienie domyślne programu Visual Studio. Jeśli debugowanie nie działa, upewnij się, że wybrano opcję .
- Jeśli środowisko używa serwera proxy HTTP, upewnij się, że
localhostjest on uwzględniony w ustawieniach obejścia serwera proxy. Można to zrobić, ustawiając zmiennąNO_PROXYśrodowiskową w dowolnym z następujących elementów:-
launchSettings.jsonPlik dla projektu. - Na poziomie zmiennych środowiskowych użytkownika lub systemu, aby miało zastosowanie do wszystkich aplikacji. W przypadku używania zmiennej środowiskowej uruchom ponownie program Visual Studio, aby zmiany zaczęły obowiązywać.
-
- Upewnij się, że zapory lub serwery proxy nie blokują komunikacji z serwerem proxy debugowania (
NodeJSproces). Aby uzyskać więcej informacji, zobacz sekcję Konfiguracja zapory.
Punkty przerwania w OnInitialized{Async} nie są osiągane
Serwer proxy debugowania frameworka Blazor nie uruchamia się natychmiast przy uruchamianiu aplikacji, więc punkty przerwania w metodach OnInitialized{Async} cyklu życia mogą nie zostać osiągnięte. Zalecamy dodanie opóźnienia na początku treści metody w celu nadania serwerowi proxy debugowania trochę czasu na uruchomienie przed trafieniem punktu przerwania. Opóźnienie można dodać w oparciu o ifdyrektywę kompilatora, aby upewnić się, że nie występuje ono w kompilacji produkcyjnej aplikacji.
protected override void OnInitialized()
{
#if DEBUG
Thread.Sleep(10000);
#endif
...
}
protected override async Task OnInitializedAsync()
{
#if DEBUG
await Task.Delay(10000);
#endif
...
}
Limit czasu w programie Visual Studio (Windows)
Jeśli program Visual Studio zgłasza wyjątek informujący, że nie można uruchomić adaptera debugera, z informacją, że upłynął limit czasu, możesz dostosować limit czasu za pomocą ustawienia rejestru:
VsRegEdit.exe set "<VSInstallFolder>" HKCU JSDebugger\Options\Debugging "BlazorTimeoutInMilliseconds" dword {TIMEOUT}
Symbol zastępczy {TIMEOUT} w poprzednim poleceniu jest podawany w milisekundach. Na przykład jedna minuta jest przypisywana jako 60000.
Kontrola funkcji Przeładowywanie na gorąco
Właściwość WasmEnableHotReload MSBuild umożliwia Szybkie Przeładowanie i jest domyślnie ustawiona na true podczas budowania w konfiguracji Debug. Funkcja przeładowywania na gorąco nie jest włączona (ustawiona na false) podczas kompilowania w jakiejkolwiek innej konfiguracji.
pl-PL: Aby użyć niestandardowej nazwy konfiguracji podczas debugowania, na przykład DebugWebAssembly, ustaw właściwość na true, aby umożliwić przeładowanie na gorąco.
<PropertyGroup>
<WasmEnableHotReload>true</WasmEnableHotReload>
</PropertyGroup>
Aby wyłączyć przeładowywanie na gorąco dla Debug konfiguracji, ustaw wartość na false:
<PropertyGroup>
<WasmEnableHotReload>false</WasmEnableHotReload>
</PropertyGroup>