Eseguire il debug ASP.NET CoreBlazor WebAssembly

Blazor WebAssemblyÈ possibile eseguire il debug delle app usando gli strumenti di sviluppo del browser Chromium browser basati su Chromium (Edge/Chrome). È anche possibile eseguire il debug dell'app usando gli ambienti di sviluppo integrato (IDE) seguenti:

  • Visual Studio
  • Visual Studio per Mac
  • Visual Studio Code

Gli scenari disponibili includono:

  • Impostare e rimuovere punti di interruzione.
  • Eseguire l'app con il supporto del debug negli ID.
  • Eseguire il codice un'istruzione alla riga di codice.
  • Riprendere l'esecuzione del codice con un tasto di scelta rapida negli ID.
  • Nella finestra Variabili locali osservare i valori delle variabili locali.
  • Vedere lo stack di chiamate, incluse le catene di chiamate tra JavaScript e .NET.

Per il momento, non è possibile:

  • Interruzione in base alle eccezioni non gestite.
  • Raggiunto i punti di interruzione durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.
  • Eseguire il debug in scenari non locali , ad esempio sottosistema Windows per Linux (WSL) o Visual Studio Codespaces).
  • Ricompilare automaticamente *Server* l'app back-end di una soluzione ospitata durante il debug, ad esempio Blazor WebAssembly eseguendo l'app con dotnet watch run .

Prerequisiti

Il debug richiede uno dei browser seguenti:

  • Google Chrome (versione 70 o successiva) (impostazione predefinita)
  • Microsoft Edge (versione 80 o successiva)

Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Visual Studio Code gli utenti richiedono le estensioni seguenti:

Dopo aver aperto un progetto in VS Code, è possibile ricevere una notifica che indica che è necessaria una configurazione aggiuntiva per abilitare il debug. Se richiesto, installare le estensioni necessarie da Visual Studio Marketplace. Per esaminare le estensioni installate, aprire Visualizza > estensioni dalla barra dei menu o selezionare l'icona Estensioni nella barra laterale Attività.

Visual Studio per Mac richiede la versione 8.8 (build 1532) o successiva:

  1. Installare la versione più recente Visual Studio per Mac selezionando il pulsante Scarica Visual Studio per Mac in Microsoft: Visual Studio per Mac.
  2. Selezionare il canale Anteprima dall'interno Visual Studio. Per altre informazioni, vedere Installare una versione di anteprima di Visual Studio per Mac.

Nota

Apple Safari in macOS non è attualmente supportato.

Eseguire il debug di Blazor WebAssembly un'app autonoma

Per abilitare il debug per un'app esistente, aggiornare il file nel progetto di avvio in modo da Blazor WebAssembly includere la proprietà seguente in ogni profilo di launchSettings.json inspectUri avvio:

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

Dopo l'aggiornamento, launchSettings.json il file dovrebbe essere simile all'esempio seguente:

{
    "iisSettings": {
      "windowsAuthentication": false,
      "anonymousAuthentication": true,
      "iisExpress": {
        "applicationUrl": "http://localhost:50454",
        "sslPort": 44399
      }
    },
    "profiles": {
      "IIS Express": {
        "commandName": "IISExpress",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      },
      "BlazorApp1.Server": {
        "commandName": "Project",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "applicationUrl": "https://localhost:5001;http://localhost:5000",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      }
    }
  }

La inspectUri proprietà :

  • Consente all'IDE di rilevare che l'app è Blazor WebAssembly un'app.
  • Indica all'infrastruttura di debug degli script di connettersi al browser tramite Blazor il proxy di debug di .

I valori segnaposto per il protocollo WebSockets ( ), l'host ( ), la porta ( ) e l'URI di controllo nel browser avviato ( ) vengono wsProtocol url.hostname forniti dal url.port browserInspectUri framework.

Per eseguire il debug Blazor WebAssembly di un'app in Visual Studio:

  1. Creare una nuova soluzione Blazor WebAssembly ospitata.

  2. Con il Server progetto selezionato in Esplora soluzioni, premere F5 per eseguire l'app nel debugger.

    Nota

    Avvia senza eseguire debug (CTRL + F5) non è supportato. Quando l'app viene eseguita nella configurazione di debug, il sovraccarico del debug comporta sempre una riduzione ridotta delle prestazioni.

  3. *Client*Nell'app impostare un punto di interruzione sulla riga in currentCount++; Pages/Counter.razor .

  4. Nel browser passare alla pagina e selezionare il pulsante Click me per raggiungere il Counter punto di interruzione.

  5. In Visual Studio controllare il valore del currentCount campo nella finestra Variabili locali.

  6. Premere F5 per continuare l'esecuzione.

Durante il debug di Blazor WebAssembly un'app, è anche possibile eseguire il debug del codice server:

  1. Impostare un punto di interruzione Pages/FetchData.razor nella pagina in OnInitializedAsync .
  2. Impostare un punto di interruzione WeatherForecastController in nel metodo di Get azione.
  3. Passare alla pagina per individuare il primo punto di interruzione nel componente appena prima che Fetch Data venga inviata una richiesta HTTP al FetchData server.
  4. Premere F5 per continuare l'esecuzione e quindi premere il punto di interruzione nel server in WeatherForecastController .
  5. Premere di nuovo F5 per consentire la continuazione dell'esecuzione e visualizzare la tabella delle previsioni meteo di cui è stato eseguito il rendering nel browser.

Nota

I punti di interruzione non vengono raggiunto durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.

Se l'app è ospitata in un percorso di base dell'app diverso da , aggiornare le proprietà seguenti in per riflettere / il percorso di base Properties/launchSettings.json dell'app:

  • applicationUrl:

    "iisSettings": {
      ...
      "iisExpress": {
        "applicationUrl": "http://localhost:{INSECURE PORT}/{APP BASE PATH}/",
        "sslPort": {SECURE PORT}
      }
    },
    
  • inspectUri di ogni profilo:

    "profiles": {
      ...
      "{PROFILE 1, 2, ... N}": {
        ...
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/{APP BASE PATH}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        ...
      }
    }
    

I segnaposto nelle impostazioni precedenti:

  • {INSECURE PORT}: porta non sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {APP BASE PATH}: percorso di base dell'app.
  • {SECURE PORT}: porta sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {PROFILE 1, 2, ... N}: avvia i profili delle impostazioni. In genere, un'app specifica più di un profilo per impostazione predefinita, ad esempio un profilo per IIS Express e un profilo di progetto, usato dal Kestrel server.

Negli esempi seguenti l'app è ospitata in con /OAT un percorso di base dell'app configurato in come wwwroot/index.html <base href="/OAT/"> :

"applicationUrl": "http://localhost:{INSECURE PORT}/OAT/",
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/OAT/_framework/debug/ws-proxy?browser={browserInspectUri}",

Per informazioni sull'uso di un percorso di base dell'app personalizzato Blazor WebAssembly per le app, vedere Ospitare e distribuire ASP.NET CoreBlazor .

Eseguire il debug nel browser

Le indicazioni in questa sezione si applicano a Google Chrome e Microsoft Edge in esecuzione Windows.

  1. Eseguire una build di debug dell'app nell'ambiente di sviluppo.

  2. Avviare un browser e passare all'URL dell'app, ad esempio https://localhost:5001 .

  3. Nel browser provare ad avviare il debug remoto premendo MAIUSC + ALT + d.

    Il browser deve essere in esecuzione con il debug remoto abilitato, che non è l'impostazione predefinita. Se il debug remoto è disabilitato, viene visualizzata la pagina di errore Impossibile trovare la scheda del browser disponibile per il debug con le istruzioni per avviare il browser con la porta di debug aperta. Seguire le istruzioni per il browser, che apre una nuova finestra del browser. Chiudere la finestra del browser precedente.

  1. Quando il browser è in esecuzione con il debug remoto abilitato, il tasto di scelta rapida per il debug nel passaggio precedente apre una nuova scheda del debugger.

  2. Dopo qualche istante, la scheda Origini mostra un elenco degli assembly .NET dell'app all'interno del file:// nodo.

  3. Nel codice del componente (file ) e nei file di codice C# ( ), i punti di interruzione impostati vengono raggiunto .razor quando viene eseguito il .cs codice. Dopo aver raggiunto un punto di interruzione, eseguire normalmente l'esecuzione del codice a un solo passaggio (F10) tramite il codice o riprendere (F8).

Blazor fornisce un proxy di debug che implementa il protocollo DevTools di Chrome e aumenta il protocollo con . Informazioni specifiche di NET. Quando si preme il tasto di scelta rapida per il debug, Blazor chrome DevTools punta al proxy. Il proxy si connette alla finestra del browser di cui si sta cercando di eseguire il debug(da qui la necessità di abilitare il debug remoto).

Mappe di origine del browser

Le mappe di origine del browser consentono al browser di eseguire il mapping dei file compilati ai file di origine originali e vengono comunemente usate per il debug sul lato client. Tuttavia, Blazor attualmente non esegue il mapping di C# direttamente a JavaScript/WASM. Al contrario, Blazor interpreta IL all'interno del browser, quindi le mappe di origine non sono pertinenti.

Configurazione del firewall

Se un firewall blocca la comunicazione con il proxy di debug, creare una regola di eccezione del firewall che consenta la comunicazione tra il browser e il NodeJS processo.

Avviso

La modifica di una configurazione del firewall deve essere effettuata con cautela per evitare la creazione di vulnerabilità di sicurezza. Applicare attentamente le linee guida sulla sicurezza, seguire le procedure consigliate per la sicurezza e rispettare gli avvisi generati dal produttore del firewall.

Autorizzazione della comunicazione aperta con il NodeJS processo:

  • Apre il server Node a qualsiasi connessione, a seconda delle funzionalità e della configurazione del firewall.
  • Potrebbe essere rischioso a seconda della rete.
  • È consigliato solo nei computer di sviluppo.

Se possibile, consentire solo la comunicazione aperta con il NodeJS processo in reti attendibili o private.

Per Windows sulla configurazione del firewall, vedere Creare un programma in ingresso o una regola del servizio. Per altre informazioni, vedere Windows Defender firewall con sicurezza avanzata e gli articoli correlati nel set di Windows firewall.

Risolvere problemi

Se si verificano errori, i suggerimenti seguenti possono essere utili:

  • Nella scheda Debugger aprire gli strumenti di sviluppo nel browser. Nella console eseguire per rimuovere localStorage.clear() eventuali punti di interruzione.
  • Verificare di aver installato e considerato attendibile il certificato ASP.NET Core di sviluppo HTTPS. Per altre informazioni, vedere Applicare HTTPS in ASP.NET Core.
  • Visual Studio richiede l'opzione Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) in Strumenti > Opzioni > Debug > Generale. Questa è l'impostazione predefinita per Visual Studio. Se il debug non funziona, verificare che l'opzione sia selezionata.
  • Se l'ambiente usa un proxy HTTP, assicurarsi che localhost sia incluso nelle impostazioni di bypass del proxy. Questa operazione può essere eseguita impostando la NO_PROXY variabile di ambiente in:
    • File launchSettings.json per il progetto.
    • A livello di utente o di ambiente di sistema per l'applicazione a tutte le app. Quando si usa una variabile di ambiente, riavviare Visual Studio per l'applicazione della modifica.
  • Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Punti di interruzione in OnInitialized{Async} non raggiunto

L'avvio del proxy di debug del framework richiede poco tempo, quindi i punti di interruzione nei metodi del ciclo di Blazor vita potrebbero non essere raggiunto. OnInitialized{Async} È consigliabile aggiungere un ritardo all'inizio del corpo del metodo per concedere al proxy di debug un certo tempo per l'avvio prima che venga raggiunto il punto di interruzione. È possibile includere il ritardo in base a una direttiva if del compilatore per assicurarsi che il ritardo non sia presente per una build di rilascio dell'app.

OnInitialized:

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

    ...
}

OnInitializedAsync:

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

    ...
}

Visual Studio (Windows)

Se Visual Studio genera un'eccezione che indica che non è stato possibile avviare l'adattatore di debug indicando che è stato raggiunto il timeout, è possibile modificare il timeout con un'impostazione del Registro di sistema:

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

Il {TIMEOUT} segnaposto nel comando precedente è espresso in millisecondi. Ad esempio, un minuto viene assegnato come 60000 .

Blazor WebAssemblyÈ possibile eseguire il debug delle app usando gli strumenti di sviluppo del browser Chromium browser basati su Chromium (Edge/Chrome). È anche possibile eseguire il debug dell'app usando gli ambienti di sviluppo integrato (IDE) seguenti:

  • Visual Studio
  • Visual Studio per Mac
  • Visual Studio Code

Gli scenari disponibili includono:

  • Impostare e rimuovere punti di interruzione.
  • Eseguire l'app con il supporto del debug negli ID.
  • Eseguire il codice un'istruzione alla riga di codice.
  • Riprendere l'esecuzione del codice con un tasto di scelta rapida negli ID.
  • Nella finestra Variabili locali osservare i valori delle variabili locali.
  • Vedere lo stack di chiamate, incluse le catene di chiamate tra JavaScript e .NET.

Per il momento, non è possibile:

  • Interruzione in base alle eccezioni non gestite.
  • Raggiunto i punti di interruzione durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.
  • Eseguire il debug in scenari non locali , ad esempio sottosistema Windows per Linux (WSL) o Visual Studio Codespaces).
  • Ricompilare automaticamente *Server* l'app back-end di una soluzione ospitata durante il debug, ad esempio Blazor WebAssembly eseguendo l'app con dotnet watch run .

Prerequisiti

Il debug richiede uno dei browser seguenti:

  • Google Chrome (versione 70 o successiva) (impostazione predefinita)
  • Microsoft Edge (versione 80 o successiva)

Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Visual Studio Code gli utenti richiedono le estensioni seguenti:

Dopo aver aperto un progetto in VS Code, è possibile ricevere una notifica che indica che è necessaria una configurazione aggiuntiva per abilitare il debug. Se richiesto, installare le estensioni necessarie da Visual Studio Marketplace. Per esaminare le estensioni installate, aprire Visualizza > estensioni dalla barra dei menu o selezionare l'icona Estensioni nella barra laterale Attività.

Visual Studio per Mac richiede la versione 8.8 (build 1532) o successiva:

  1. Installare la versione più recente Visual Studio per Mac selezionando il pulsante Scarica Visual Studio per Mac in Microsoft: Visual Studio per Mac.
  2. Selezionare il canale Anteprima dall'interno Visual Studio. Per altre informazioni, vedere Installare una versione di anteprima di Visual Studio per Mac.

Nota

Apple Safari in macOS non è attualmente supportato.

Eseguire il debug di Blazor WebAssembly un'app autonoma

Per abilitare il debug per un'app esistente, aggiornare il file nel progetto di avvio in modo da Blazor WebAssembly includere la proprietà seguente in ogni profilo di launchSettings.json inspectUri avvio:

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

Dopo l'aggiornamento, launchSettings.json il file dovrebbe essere simile all'esempio seguente:

{
    "iisSettings": {
      "windowsAuthentication": false,
      "anonymousAuthentication": true,
      "iisExpress": {
        "applicationUrl": "http://localhost:50454",
        "sslPort": 44399
      }
    },
    "profiles": {
      "IIS Express": {
        "commandName": "IISExpress",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      },
      "BlazorApp1.Server": {
        "commandName": "Project",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "applicationUrl": "https://localhost:5001;http://localhost:5000",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      }
    }
  }

La inspectUri proprietà :

  • Consente all'IDE di rilevare che l'app è Blazor WebAssembly un'app.
  • Indica all'infrastruttura di debug degli script di connettersi al browser tramite Blazor il proxy di debug di .

I valori segnaposto per il protocollo WebSockets ( ), l'host ( ), la porta ( ) e l'URI di controllo nel browser avviato ( ) vengono wsProtocol url.hostname forniti dal url.port browserInspectUri framework.

Per eseguire il debug Blazor WebAssembly di un'app in Visual Studio:

  1. Creare una nuova soluzione Blazor WebAssembly ospitata.

  2. Con il Server progetto selezionato in Esplora soluzioni, premere F5 per eseguire l'app nel debugger.

    Nota

    Avvia senza eseguire debug (CTRL + F5) non è supportato. Quando l'app viene eseguita nella configurazione di debug, il sovraccarico del debug comporta sempre una riduzione ridotta delle prestazioni.

  3. *Client*Nell'app impostare un punto di interruzione sulla riga in currentCount++; Pages/Counter.razor .

  4. Nel browser passare alla pagina e selezionare il pulsante Click me per raggiungere il punto Counter di interruzione.

  5. In Visual Studio controllare il valore del currentCount campo nella finestra Variabili locali.

  6. Premere F5 per continuare l'esecuzione.

Durante il debug di Blazor WebAssembly un'app, è anche possibile eseguire il debug del codice server:

  1. Impostare un punto di interruzione nella Pages/FetchData.razor pagina in OnInitializedAsync .
  2. Impostare un punto di interruzione WeatherForecastController in nel metodo di Get azione.
  3. Passare alla pagina per individuare il primo punto di interruzione nel componente appena prima che Fetch Data venga inviata una richiesta HTTP al FetchData server.
  4. Premere F5 per continuare l'esecuzione e quindi premere il punto di interruzione nel server in WeatherForecastController .
  5. Premere di nuovo F5 per consentire la continuazione dell'esecuzione e visualizzare la tabella delle previsioni meteo di cui è stato eseguito il rendering nel browser.

Nota

I punti di interruzione non vengono raggiunto durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.

Se l'app è ospitata in un percorso di base dell'app diverso da , aggiornare le proprietà seguenti in per riflettere / il percorso di base Properties/launchSettings.json dell'app:

  • applicationUrl:

    "iisSettings": {
      ...
      "iisExpress": {
        "applicationUrl": "http://localhost:{INSECURE PORT}/{APP BASE PATH}/",
        "sslPort": {SECURE PORT}
      }
    },
    
  • inspectUri di ogni profilo:

    "profiles": {
      ...
      "{PROFILE 1, 2, ... N}": {
        ...
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/{APP BASE PATH}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        ...
      }
    }
    

I segnaposto nelle impostazioni precedenti:

  • {INSECURE PORT}: porta non sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {APP BASE PATH}: percorso di base dell'app.
  • {SECURE PORT}: porta sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {PROFILE 1, 2, ... N}: avvia i profili delle impostazioni. In genere, un'app specifica più di un profilo per impostazione predefinita, ad esempio un profilo per IIS Express e un profilo di progetto, usato dal Kestrel server.

Negli esempi seguenti l'app è ospitata in con /OAT un percorso di base dell'app configurato in come wwwroot/index.html <base href="/OAT/"> :

"applicationUrl": "http://localhost:{INSECURE PORT}/OAT/",
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/OAT/_framework/debug/ws-proxy?browser={browserInspectUri}",

Per informazioni sull'uso di un percorso di base dell'app personalizzato Blazor WebAssembly per le app, vedere Ospitare e distribuire ASP.NET CoreBlazor .

Eseguire il debug nel browser

Le indicazioni in questa sezione si applicano a Google Chrome e Microsoft Edge in esecuzione Windows.

  1. Eseguire una build di debug dell'app nell'ambiente di sviluppo.

  2. Avviare un browser e passare all'URL dell'app, ad esempio https://localhost:5001 .

  3. Nel browser provare ad avviare il debug remoto premendo MAIUSC + ALT + d.

    Il browser deve essere in esecuzione con il debug remoto abilitato, che non è l'impostazione predefinita. Se il debug remoto è disabilitato, viene visualizzata la pagina di errore Impossibile trovare la scheda del browser disponibile per il debug con le istruzioni per avviare il browser con la porta di debug aperta. Seguire le istruzioni per il browser, che apre una nuova finestra del browser. Chiudere la finestra del browser precedente.

  1. Quando il browser è in esecuzione con il debug remoto abilitato, il tasto di scelta rapida per il debug nel passaggio precedente apre una nuova scheda del debugger.

  2. Dopo qualche istante, la scheda Origini mostra un elenco degli assembly .NET dell'app all'interno del file:// nodo.

  3. Nel codice del componente (file ) e nei file di codice C# ( ), i punti di interruzione impostati vengono raggiunto .razor quando viene eseguito il .cs codice. Dopo aver raggiunto un punto di interruzione, eseguire normalmente l'esecuzione del codice a un solo passaggio (F10) tramite il codice o riprendere (F8).

Blazor fornisce un proxy di debug che implementa il protocollo DevTools di Chrome e aumenta il protocollo con . Informazioni specifiche di NET. Quando si preme il tasto di scelta rapida per il debug, Blazor chrome DevTools punta al proxy. Il proxy si connette alla finestra del browser di cui si sta cercando di eseguire il debug(da qui la necessità di abilitare il debug remoto).

Mappe di origine del browser

Le mappe di origine del browser consentono al browser di eseguire il mapping dei file compilati ai file di origine originali e vengono comunemente usate per il debug sul lato client. Tuttavia, Blazor attualmente non esegue il mapping di C# direttamente a JavaScript/WASM. Al contrario, Blazor interpreta IL all'interno del browser, quindi le mappe di origine non sono pertinenti.

Configurazione del firewall

Se un firewall blocca la comunicazione con il proxy di debug, creare una regola di eccezione del firewall che consenta la comunicazione tra il browser e il NodeJS processo.

Avviso

La modifica di una configurazione del firewall deve essere effettuata con cautela per evitare la creazione di vulnerabilità di sicurezza. Applicare attentamente le linee guida sulla sicurezza, seguire le procedure consigliate per la sicurezza e rispettare gli avvisi generati dal produttore del firewall.

Autorizzazione della comunicazione aperta con il NodeJS processo:

  • Apre il server Node a qualsiasi connessione, a seconda delle funzionalità e della configurazione del firewall.
  • Potrebbe essere rischioso a seconda della rete.
  • È consigliato solo nei computer di sviluppo.

Se possibile, consentire solo la comunicazione aperta con il NodeJS processo in reti attendibili o private.

Per Windows sulla configurazione del firewall, vedere Creare un programma in ingresso o una regola del servizio. Per altre informazioni, vedere Windows Defender firewall con sicurezza avanzata e gli articoli correlati nel set di Windows firewall.

Risolvere problemi

Se si verificano errori, i suggerimenti seguenti possono essere utili:

  • Nella scheda Debugger aprire gli strumenti di sviluppo nel browser. Nella console eseguire per rimuovere localStorage.clear() eventuali punti di interruzione.
  • Verificare di aver installato e considerato attendibile il certificato ASP.NET Core di sviluppo HTTPS. Per altre informazioni, vedere Applicare HTTPS in ASP.NET Core.
  • Visual Studio richiede l'opzione Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) in Strumenti > Opzioni > Debug > Generale. Questa è l'impostazione predefinita per Visual Studio. Se il debug non funziona, verificare che l'opzione sia selezionata.
  • Se l'ambiente usa un proxy HTTP, assicurarsi che localhost sia incluso nelle impostazioni di bypass del proxy. Questa operazione può essere eseguita impostando la NO_PROXY variabile di ambiente in:
    • File launchSettings.json per il progetto.
    • A livello di utente o di ambiente di sistema per l'applicazione a tutte le app. Quando si usa una variabile di ambiente, riavviare Visual Studio per l'applicazione della modifica.
  • Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Punti di interruzione in OnInitialized{Async} non raggiunto

L'avvio del proxy di debug del framework richiede poco tempo, quindi i punti di interruzione nei metodi del ciclo di Blazor vita potrebbero non essere raggiunto. OnInitialized{Async} È consigliabile aggiungere un ritardo all'inizio del corpo del metodo per concedere al proxy di debug un certo tempo per l'avvio prima che venga raggiunto il punto di interruzione. È possibile includere il ritardo in base a una direttiva if del compilatore per assicurarsi che il ritardo non sia presente per una build di rilascio dell'app.

OnInitialized:

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

    ...
}

OnInitializedAsync:

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

    ...
}

Visual Studio (Windows)

Se Visual Studio genera un'eccezione che indica che non è stato possibile avviare l'adattatore di debug indicando che è stato raggiunto il timeout, è possibile modificare il timeout con un'impostazione del Registro di sistema:

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

Il {TIMEOUT} segnaposto nel comando precedente è espresso in millisecondi. Ad esempio, un minuto viene assegnato come 60000 .

Blazor WebAssemblyÈ possibile eseguire il debug delle app usando gli strumenti di sviluppo del browser Chromium browser basati su Chromium (Edge/Chrome). È anche possibile eseguire il debug dell'app usando gli ambienti di sviluppo integrato (IDE) seguenti:

  • Visual Studio
  • Visual Studio per Mac
  • Visual Studio Code

Gli scenari disponibili includono:

  • Impostare e rimuovere punti di interruzione.
  • Eseguire l'app con il supporto del debug negli ID.
  • Eseguire il codice un'istruzione alla riga di codice.
  • Riprendere l'esecuzione del codice con un tasto di scelta rapida negli ID.
  • Nella finestra Variabili locali osservare i valori delle variabili locali.
  • Vedere lo stack di chiamate, incluse le catene di chiamate tra JavaScript e .NET.

Per il momento, non è possibile:

  • Interruzione in base alle eccezioni non gestite.
  • Raggiunto i punti di interruzione durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.
  • Eseguire il debug in scenari non locali ( ad esempio, sottosistema Windows per Linux (WSL) o Visual Studio Codespaces).
  • Ricompilare automaticamente l'app back-end di una soluzione ospitata durante il debug, ad esempio *Server* Blazor WebAssembly eseguendo l'app con dotnet watch run .

Prerequisiti

Il debug richiede uno dei browser seguenti:

  • Google Chrome (versione 70 o successiva) (impostazione predefinita)
  • Microsoft Edge (versione 80 o successiva)

Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Visual Studio Code gli utenti richiedono le estensioni seguenti:

Dopo aver aperto un progetto in VS Code, è possibile ricevere una notifica che indica che è necessaria una configurazione aggiuntiva per abilitare il debug. Se richiesto, installare le estensioni necessarie da Visual Studio Marketplace. Per esaminare le estensioni installate, aprire Visualizza > estensioni dalla barra dei menu o selezionare l'icona Estensioni nella barra laterale Attività.

Visual Studio per Mac richiede la versione 8.8 (build 1532) o successiva:

  1. Installare la versione più recente Visual Studio per Mac selezionando il pulsante Scarica Visual Studio per Mac in Microsoft: Visual Studio per Mac.
  2. Selezionare il canale Anteprima dall'interno Visual Studio. Per altre informazioni, vedere Installare una versione di anteprima di Visual Studio per Mac.

Nota

Apple Safari in macOS non è attualmente supportato.

Eseguire il debug di Blazor WebAssembly un'app autonoma

Per abilitare il debug per un'app esistente, aggiornare il file nel progetto di avvio in modo da Blazor WebAssembly includere la proprietà seguente in ogni profilo di launchSettings.json inspectUri avvio:

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

Dopo l'aggiornamento, launchSettings.json il file dovrebbe essere simile all'esempio seguente:

{
    "iisSettings": {
      "windowsAuthentication": false,
      "anonymousAuthentication": true,
      "iisExpress": {
        "applicationUrl": "http://localhost:50454",
        "sslPort": 44399
      }
    },
    "profiles": {
      "IIS Express": {
        "commandName": "IISExpress",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      },
      "BlazorApp1.Server": {
        "commandName": "Project",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "applicationUrl": "https://localhost:5001;http://localhost:5000",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
        }
      }
    }
  }

La inspectUri proprietà :

  • Consente all'IDE di rilevare che l'app è Blazor WebAssembly un'app.
  • Indica all'infrastruttura di debug degli script di connettersi al browser tramite Blazor il proxy di debug di .

I valori segnaposto per il protocollo WebSockets ( ), l'host ( ), la porta ( ) e l'URI di controllo nel browser avviato ( ) vengono wsProtocol url.hostname forniti dal url.port browserInspectUri framework.

Per eseguire il debug Blazor WebAssembly di un'app in Visual Studio:

  1. Creare una nuova soluzione Blazor WebAssembly ospitata.

  2. Con il Server progetto selezionato in Esplora soluzioni, premere F5 per eseguire l'app nel debugger.

    Nota

    Avvia senza eseguire debug (CTRL + F5) non è supportato. Quando l'app viene eseguita nella configurazione di debug, il sovraccarico del debug comporta sempre una riduzione ridotta delle prestazioni.

  3. *Client*Nell'app impostare un punto di interruzione nella riga in currentCount++; Pages/Counter.razor .

  4. Nel browser passare alla pagina e selezionare il pulsante Click me per raggiungere il punto Counter di interruzione.

  5. In Visual Studio controllare il valore del currentCount campo nella finestra Variabili locali.

  6. Premere F5 per continuare l'esecuzione.

Durante il debug di Blazor WebAssembly un'app, è anche possibile eseguire il debug del codice server:

  1. Impostare un punto di interruzione nella Pages/FetchData.razor pagina in OnInitializedAsync .
  2. Impostare un punto di interruzione WeatherForecastController in nel metodo di Get azione.
  3. Passare alla pagina per individuare il primo punto di interruzione nel componente appena prima che Fetch Data venga inviata una richiesta HTTP al FetchData server.
  4. Premere F5 per continuare l'esecuzione e quindi premere il punto di interruzione nel server in WeatherForecastController .
  5. Premere di nuovo F5 per consentire la continuazione dell'esecuzione e visualizzare la tabella delle previsioni meteo di cui è stato eseguito il rendering nel browser.

Nota

I punti di interruzione non vengono raggiunto durante l'avvio dell'app prima dell'esecuzione del proxy di debug. Sono inclusi i punti di interruzione in ( ) e i punti di interruzione nei metodi del ciclo di vita dei componenti caricati dalla prima Program.Main Program.cs pagina richiesta OnInitialized{Async} dall'app.

Se l'app è ospitata in un percorso di base dell'app diverso da , aggiornare le proprietà seguenti in per riflettere / il percorso di base Properties/launchSettings.json dell'app:

  • applicationUrl:

    "iisSettings": {
      ...
      "iisExpress": {
        "applicationUrl": "http://localhost:{INSECURE PORT}/{APP BASE PATH}/",
        "sslPort": {SECURE PORT}
      }
    },
    
  • inspectUri di ogni profilo:

    "profiles": {
      ...
      "{PROFILE 1, 2, ... N}": {
        ...
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/{APP BASE PATH}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        ...
      }
    }
    

I segnaposto nelle impostazioni precedenti:

  • {INSECURE PORT}: porta non sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {APP BASE PATH}: percorso di base dell'app.
  • {SECURE PORT}: porta sicura. Per impostazione predefinita viene fornito un valore casuale, ma è consentita una porta personalizzata.
  • {PROFILE 1, 2, ... N}: avvia i profili delle impostazioni. In genere, un'app specifica più di un profilo per impostazione predefinita, ad esempio un profilo per IIS Express e un profilo di progetto, usato dal Kestrel server.

Negli esempi seguenti l'app è ospitata in con /OAT un percorso di base dell'app configurato in come wwwroot/index.html <base href="/OAT/"> :

"applicationUrl": "http://localhost:{INSECURE PORT}/OAT/",
"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/OAT/_framework/debug/ws-proxy?browser={browserInspectUri}",

Per informazioni sull'uso di un percorso di base dell'app personalizzato Blazor WebAssembly per le app, vedere Ospitare e distribuire ASP.NET CoreBlazor .

Eseguire il debug nel browser

Le indicazioni riportate in questa sezione si applicano a Google Chrome e Microsoft Edge in esecuzione Windows.

  1. Eseguire una build di debug dell'app nell'ambiente di sviluppo.

  2. Avviare un browser e passare all'URL dell'app , ad esempio https://localhost:5001 .

  3. Nel browser tentare di avviare il debug remoto premendo + MAIUSC ALT + d.

    Il browser deve essere in esecuzione con il debug remoto abilitato, che non è l'impostazione predefinita. Se il debug remoto è disabilitato, viene visualizzata la pagina di errore Impossibile trovare la scheda del browser disponibile per il debug con le istruzioni per avviare il browser con la porta di debug aperta. Seguire le istruzioni per il browser, che apre una nuova finestra del browser. Chiudere la finestra del browser precedente.

  1. Quando il browser è in esecuzione con il debug remoto abilitato, la scelta rapida da tastiera per il debug nel passaggio precedente apre una nuova scheda del debugger.

  2. Dopo un po', la scheda Origini mostra un elenco degli assembly .NET dell'app all'interno del file:// nodo.

  3. Nei file di codice del componente (file) e C# ( ), i punti di interruzione impostati vengono raggiunto .razor quando viene eseguito il .cs codice. Dopo aver raggiunto un punto di interruzione, eseguire normalmente l'esecuzione del codice a passaggio singolo (F10) tramite il codice o riprendere (F8).

Blazor fornisce un proxy di debug che implementa il protocollo Chrome DevTools e aumenta il protocollo con . Informazioni specifiche di NET. Quando viene premuto il tasto di scelta rapida per il debug, Blazor punta Chrome DevTools al proxy. Il proxy si connette alla finestra del browser di cui si sta cercando di eseguire il debug (da qui la necessità di abilitare il debug remoto).

Mappe di origine del browser

Le mappe di origine del browser consentono al browser di eseguire il mapping dei file compilati ai file di origine originali e vengono comunemente usate per il debug sul lato client. Tuttavia, Blazor attualmente non esegue il mapping di C# direttamente a JavaScript/WASM. Al contrario, Blazor interpreta IL all'interno del browser, quindi le mappe di origine non sono pertinenti.

Configurazione del firewall

Se un firewall blocca la comunicazione con il proxy di debug, creare una regola di eccezione del firewall che consenta la comunicazione tra il browser e il NodeJS processo.

Avviso

La modifica di una configurazione del firewall deve essere effettuata con cautela per evitare la creazione di vulnerabilità di sicurezza. Applicare attentamente le linee guida sulla sicurezza, seguire le procedure consigliate per la sicurezza e rispettare gli avvisi generati dal produttore del firewall.

Autorizzazione della comunicazione aperta con il NodeJS processo:

  • Apre il server Node a qualsiasi connessione, a seconda delle funzionalità e della configurazione del firewall.
  • Potrebbe essere rischioso a seconda della rete.
  • È consigliato solo nei computer di sviluppo.

Se possibile, consentire solo la comunicazione aperta con il NodeJS processo in reti attendibili o private.

Per Windows sulla configurazione del firewall, vedere Creare un programma in ingresso o una regola del servizio. Per altre informazioni, vedere Windows Defender firewall con sicurezza avanzata e gli articoli correlati nel set di Windows firewall.

Risolvere problemi

Se si verificano errori, i suggerimenti seguenti possono essere utili:

  • Nella scheda Debugger aprire gli strumenti di sviluppo nel browser. Nella console eseguire per localStorage.clear() rimuovere eventuali punti di interruzione.
  • Verificare di aver installato e considerato attendibile il certificato ASP.NET Core di sviluppo HTTPS. Per altre informazioni, vedere Applicare HTTPS in ASP.NET Core.
  • Visual Studio richiede l'opzione Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) in Strumenti > Opzioni > Debug > Generale. Questa è l'impostazione predefinita per Visual Studio. Se il debug non funziona, verificare che l'opzione sia selezionata.
  • Se l'ambiente usa un proxy HTTP, assicurarsi che localhost sia incluso nelle impostazioni di bypass del proxy. Questa operazione può essere eseguita impostando la NO_PROXY variabile di ambiente in:
    • File launchSettings.json per il progetto.
    • A livello di utente o di ambiente di sistema per l'applicazione a tutte le app. Quando si usa una variabile di ambiente, riavviare Visual Studio per l'applicazione della modifica.
  • Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug NodeJS (processo ). Per altre informazioni, vedere la sezione Configurazione del firewall.

Punti di interruzione non OnInitialized{Async} raggiunto

L'avvio del proxy di debug del framework richiede poco tempo, quindi i punti di interruzione nei metodi del ciclo di Blazor vita potrebbero non essere raggiunto. OnInitialized{Async} È consigliabile aggiungere un ritardo all'inizio del corpo del metodo per concedere al proxy di debug un certo tempo per l'avvio prima che venga raggiunto il punto di interruzione. È possibile includere il ritardo in base a una direttiva if del compilatore per assicurarsi che il ritardo non sia presente per una build di rilascio dell'app.

OnInitialized:

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

    ...
}

OnInitializedAsync:

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

    ...
}

Visual Studio (Windows)

Se Visual Studio genera un'eccezione che indica che non è stato possibile avviare l'adattatore di debug indicando che è stato raggiunto il timeout, è possibile modificare il timeout con un'impostazione del Registro di sistema:

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

Il {TIMEOUT} segnaposto nel comando precedente è espresso in millisecondi. Ad esempio, un minuto viene assegnato come 60000 .