Eseguire il debug di app ASP.NET Core

Questo articolo descrive come eseguire il debug Blazor delle app, incluso il debug di Blazor WebAssembly app con strumenti di sviluppo del browser o un ambiente di sviluppo integrato (IDE).

Prerequisiti

Questa sezione illustra i prerequisiti per il debug.

Prerequisiti del browser

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

Prerequisiti dell'IDE

È necessaria la versione più recente di Visual Studio o Visual Studio Code.

Prerequisiti di Visual Studio Code

Visual Studio Code richiede C # Dev Kit per Visual Studio Code (Introduzione a C# in VS Code). In Visual Studio Code Extensions Marketplace filtrare l'elenco di estensioni con "c# dev kit" per individuare l'estensione:

L'installazione di C# Dev Kit installa automaticamente le estensioni aggiuntive seguenti:

• Strumento di installazione di .NET
• C#
• IntelliCode per C# Dev Kit

Se si verificano avvisi o errori, è possibile aprire un problema (microsoft/vscode-dotnettools repository GitHub) che descrive il problema.

Prerequisiti di configurazione dell'app

Le indicazioni contenute in questa sottosezione si applicano al debug lato client.

Aprire il Properties/launchSettings.json file del progetto di avvio. Verificare la presenza della proprietà seguente inspectUri in ogni profilo di avvio del nodo del profiles file. Se la proprietà seguente non è presente, aggiungerla a ogni profilo:

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

Proprietà inspectUri :

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

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

Pacchetti

Indipendente Blazor WebAssembly: Microsoft.AspNetCore.Components.WebAssembly.DevServer: Server di sviluppo da usare durante lo sviluppo di app Blazor WebAssembly. Chiama UseWebAssemblyDebugging internamente per aggiungere middleware per il debug delle app all'interno degli Blazor WebAssembly strumenti di sviluppo Chromium.

Eseguire il debug di un'app Blazor WebAssembly in un IDE

<DebuggerSupport>true</DebuggerSupport>
<CopyOutputSymbolsToPublishDirectory>true</CopyOutputSymbolsToPublishDirectory>

Connettersi a una sessione di debug di Visual Studio Code esistente

Per connettersi a un'app in esecuzione Blazor , aprire il .vscode/launch.json file e sostituire il {URL} segnaposto con l'URL in cui è in esecuzione l'app:

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

Opzioni di avvio di Visual Studio Code

Le opzioni di configurazione di avvio nella tabella seguente sono supportate per il blazorwasm tipo di debug (.vscode/launch.json).

Eseguire il debug Blazor WebAssembly con Google Chrome o Microsoft Edge

Le indicazioni contenute in questa sezione applicano il debug delle Blazor WebAssembly app in:

• Google Chromein esecuzione in Windows o macOS.
• microsoft Edgein esecuzione in Windows.

1. Esegui l'applicazione in una shell di comando con dotnet watch (o dotnet run).

2. Avviare un browser e passare all'URL dell'app.

3. Avviare il debug remoto premendo:

   • Maiusc+Alt+d su Windows.
   • Maiusc+⌘+d su macOS.

   Il browser deve essere in esecuzione con il debug remoto abilitato, che non è l'impostazione predefinita. Se il debug remoto è disabilitato, viene visualizzata una pagina di errore con il messaggio Impossibile trovare una scheda del browser di cui è possibile eseguire il debug e con istruzioni per avviare il browser con la porta di debug aperta. Seguire le istruzioni per il browser.

   Dopo aver seguito le istruzioni per abilitare il debug remoto, l'app viene aperta in una nuova finestra del browser. Avviare il debug remoto premendo la combinazione hotkey nella nuova finestra del browser:

   • Maiusc+Alt+d su Windows.
   • Maiusc+⌘+d su macOS.

   Viene visualizzata una nuova scheda del browser strumenti di sviluppo della finestra che mostra un'immagine fantasma dell'app.

   Nota

   Se sono state seguite le istruzioni per aprire una nuova scheda del browser con il debug remoto abilitato, è possibile chiudere la finestra originale del browser, lasciando aperta la seconda finestra con la prima scheda che esegue l'app e la seconda scheda che esegue il debugger.

4. Dopo un attimo, nella scheda Origini viene visualizzato un elenco di assembly e pagine .NET dell'app.

5. Aprire il nodo file://. Nel codice del componente (.razor file) e nei file di codice C# (.cs), i punti di interruzione impostati vengono raggiunti quando il codice viene eseguito nella scheda del browser dell'app (la scheda iniziale aperta dopo l'avvio del debug remoto). Dopo che viene raggiunto un punto di interruzione, nella scheda Debug è possibile eseguire il codice passo passo (F10) oppure riprendere normalmente l'esecuzione del codice (F8).

Per il debug dei browser basati su Chromium, Blazor fornisce un proxy di debug che implementa il Chrome DevTools Protocol ed estende il protocollo con informazioni specifiche di .NET. Quando si preme la scorciatoia da tastiera per il debug, Blazor indirizza Chrome DevTools al proxy. Il proxy si connette alla finestra del browser in cui si sta cercando di eseguire il debug (quindi la necessità di abilitare il debug remoto).

Interrompere le eccezioni non gestite

Il debugger non si interrompe sulle eccezioni non gestite perché Blazor rileva le eccezioni non gestite dal codice dello sviluppatore.

Per interrompere le eccezioni non gestite:

• Aprire le impostazioni delle eccezioni del debugger (Debug>Finestre>Impostazioni eccezioni) in Visual Studio.
• Impostare le seguenti impostazioni di Eccezioni JavaScript:
  • Tutte le eccezioni
  • Eccezioni non rilevate

Mappe sorgente 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 usati per il debug sul lato client. Tuttavia, Blazor attualmente non esegue il mapping diretto di C# a JavaScript/Wasm. Al contrario, Blazor esegue l'interpretazione IL all'interno del browser, quindi le mappe di origine non sono rilevanti.

Configurazione 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.

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

Risoluzione dei problemi

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

• Rimuovere i punti di interruzione:
  • Google Chrome: nella scheda Debugger aprire gli strumenti di sviluppo nel browser. Nella console eseguire localStorage.clear() per rimuovere eventuali punti di interruzione.
  • Microsoft Edge: nella scheda Applicazione aprire Archiviazione locale. Fare clic con il pulsante destro del mouse sul sito e scegliere Cancella.
• Verificare di aver installato e considerato attendibile il certificato di sviluppo ASP.NET Core HTTPS. Per altre informazioni, vedere Applicare HTTPS in ASP.NET Core.
• Visual Studio richiede l'opzione Abilita il debug JavaScript per ASP.NET (Chrome e Edge) 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 uno dei due casi:
  • Il file launchSettings.json per il progetto.
  • A livello di variabili di ambiente utente o di sistema per applicarlo a tutte le app. Quando si usa una variabile di ambiente, riavviare Visual Studio per rendere effettiva la modifica.
• Assicurarsi che i firewall o i proxy non blocchino la comunicazione con il proxy di debug (processo NodeJS). Per altre informazioni, vedere la sezione Configurazione del firewall.

Punti di interruzione in OnInitialized{Async} non raggiunti

Il proxy di debug del framework Blazor non si avvia immediatamente all'avvio dell'app, quindi i punti di interruzione nei OnInitialized{Async} metodi del ciclo di vita potrebbero non essere attivati. È consigliabile aggiungere un ritardo all'inizio del corpo del metodo per dare al proxy di debug il tempo di avviarsi prima che venga raggiunto il punto di interruzione. È possibile includere il ritardo in base a una if direttiva del compilatore per assicurarsi che il ritardo non sia presente per una build di versione 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

    ...
}

Timeout di Visual Studio (Windows)

Se Visual Studio genera un'eccezione che l'adattatore di debug non è riuscito ad avviare e indica 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.

<PropertyGroup>
  <WasmEnableHotReload>true</WasmEnableHotReload>
</PropertyGroup>

<PropertyGroup>
  <WasmEnableHotReload>false</WasmEnableHotReload>
</PropertyGroup>