Debug dell'estensione con Visual Studio Code
Il processo di ricerca e correzione di errori è denominato debugging. Con Visual Studio Code e l'estensione AL Language, si dispone di un debugger integrato per analizzare il codice e verificare l'esecuzione dell'applicazione. Per avviare una sessione di debug, premere il pulsante F5.
Considerare le seguenti limitazioni:
È possibile eseguire il debug del codice esterno solo se per il codice è impostato il flag showMyCode. È possibile impostare il flag showMyCode nel file di configurazione app.json.
Il debugger avvia una nuova istanza client ogni volta che si preme il tasto F5. Se si chiude la sessione di debug e quindi si avvia una nuova sessione, questa sarà basata su una nuova istanza client. Si consiglia di chiudere le istanze client Web quando si chiude una sessione di debug.
La sospensione della sessione di debug non è supportata.
Punti di interruzione
Il concetto di base del debug è il punto di interruzione, ovvero un segno impostato in un'istruzione. Quando il flusso del programma raggiunge il punto di interruzione, l'esecuzione del debugger si interrompe fino a che non viene indicato di continuare. Senza punti di interruzione, il codice viene eseguito senza interruzioni quando il debugger è attivo. È possibile impostare un punto di interruzione usando il menu Debug in Visual Studio Code, oppure premendo F9 sulla riga di cui si desidera eseguire il debug.
È possibile accedere al codice dell'applicazione di base usando la funzionalità Vai a definizione e impostare i punti di interruzione sul codice di riferimento, che generalmente è un file (.dal). Per impostare un punto di interruzione nel codice esterno o nel codice dell'applicazione di base, effettuare i seguenti passaggi.
Creare una variabile di un oggetto di base o selezionare SourceTable in una pagina.
Fare clic con il pulsante destro del mouse sulla variabile e scegliere Vai a Definizione oppure premere F12. Viene aperto un file esterno (file .dal).
Selezionare la riga in cui inserire un punto di interruzione e quindi premere F9.
Scelte rapide per debug
Durante il debug, è possibile usare alcune scelte rapide per avviare o interrompere il debug o per eseguire il codice.
F5 - Avvia debug
CTRL+F5 - Avvia senza eseguire debug
MAIUSC+F5 - Arresta debug
CTRL+MAIUSC+F5 - Avvia debug senza pubblicare. Il debugger eseguirà il debug dell'ultima versione pubblicata, non della versione attiva nell'ambiente Visual Studio Code.
ALT+F5 - Avvia la funzionalità di sviluppo rapido di applicazioni con il debug
F10 - Esegui istruzione/routine
F11 - Esegui istruzione
MAIUSC+F11 - Interrompi esecuzione
F12 - Vai alla definizione
Interruzione all'errore
Nel file di configurazione launch.json, è possibile specificare se il debugger deve interrompersi all'errore successivo usando la proprietà breakOnError. Se il debugger è impostato su breakOnError, smette di funzionare in presenza di errori gestiti nel codice e di errori non gestiti.
Il valore predefinito della proprietà breakOnError è true, a indicare che il debugger interrompe un'implementazione che genera un errore per impostazione predefinita. Per saltare il processo di gestione degli errori, impostare la proprietà breakOnError su false nel file launch.json.
L'impostazione breakOnError nel file launch.json assume uno dei seguenti valori:
true: si interrompe a tutti gli errori.
false: non si interrompe ad alcun errore.
None: non si interrompe ad alcun errore.
All: si interrompe a tutti gli errori.
ExcludeTry: si interrompe agli errori solo se si verificano al di fuori del contesto di una funzione Try.
I valori true e false sono attualmente mantenuti per compatibilità con le versioni precedenti. Sono mappati ad All e None. Si consiglia di usare gli ultimi d'ora in poi. True e false verranno deprecati in una versione futura.
Interruzione ai record modificati
Nel file di configurazione launch.json è possibile specificare se il debugger deve interrompersi ai record modificati usando la proprietà breakOnRecordWrite. Se il debugger è impostato per interrompersi ai record modificati, si interrompe prima di creare, modificare o eliminare un record.
Il valore predefinito della proprietà breakOnRecordWrite è false, a indicare che il debugger non è impostato per interrompersi ai record modificati per impostazione predefinita. Per interrompere il debugger ai record modificati, impostare la proprietà breakOnRecordWrite su true nel file launch.json.
L'impostazione breakOnRecordWrite nel file launch.json assume uno dei seguenti valori:
true: si interrompe a tutte le scritture di record.
false: non si interrompe ad alcuna scrittura di record.
None: non si interrompe ad alcuna scrittura di record.
All: si interrompe a tutte le scritture di record.
ExcludeTemporary: si interrompe alle scritture di record solo se non si trovano in una tabella temporanea.
I valori true e false sono attualmente mantenuti per compatibilità con le versioni precedenti. Sono mappati ad All e None. Si consiglia di usare gli ultimi d'ora in poi. True e false verranno deprecati in una versione futura.
Impostazioni dei criteri di esposizione delle risorse
Quando si sviluppa un'estensione, per impostazione predefinita il codice è protetto da download o debug. Continuare a leggere di seguito a proposito dell'aggiunta della protezione della proprietà intellettuale (PI) contro il download o il debug in un'estensione per vedere il codice sorgente nelle estensioni.
Il pacchetto di sviluppo delle estensioni fornisce un'impostazione preconfigurata per la protezione contro la visualizzazione o il download del codice delle estensioni. Tuttavia è possibile controllare questa impostazione anche nel manifesto, ovvero nel file app.json.
Quando si avvia un nuovo progetto, viene generato automaticamente un file app.json, che contiene le informazioni sull'estensione che si sta sviluppando. Nel file app.json è possibile specificare un'impostazione denominata resourceExposurePolicy che definisce l'accessibilità delle risorse e del codice sorgente durante varie operazioni.
L'impostazione resourceExposurePolicy specifica il seguente elenco di opzioni:
allowDebugging
allowDownloadingSource
includeSourceInSymbolFile
Ognuna di queste proprietà definisce le aree specifiche in cui è possibile accedere al codice sorgente di un'estensione. Per impostazione predefinita, le opzioni sono impostate tutte su false. In altre parole, per impostazione predefinita, nessuna estensione dipendente può eseguire il debug o il download del codice sorgente dell'estensione.
Di seguito è riportato un esempio di un file JSON con valori predefiniti quando viene generato con il comando AL: Go!:
... "resourceExposurePolicy": { "allowDebugging": true, "allowDownloadingSource": false, "includeSourceInSymbolFile": false }, "runtime": "8.0", "keyVaultUrls": [ "https://mykeyvault.vault.azure.net" ], "applicationInsightsConnectionString": "MyConnectionString1234" ...
L'impostazione resourceExposurePolicy non è visibile nel file app.json quando viene generato. Se si desidera modificare il valore predefinito false, è necessario aggiungere l'impostazione come illustrato nell'esempio di sintassi riportato sopra.
allowDebugging
Per consentire il debug nell'estensione, quando l'estensione è una dipendenza, è necessario impostare il flag allowDebugging. In caso contrario il debug non è consentito. Se si desidera consentire ai debugger nell'estensione di visualizzare il codice sorgente, è necessario impostare la proprietà allowDebugging nel file app.json su true.
Ad esempio, se uno sviluppatore sviluppa l'estensione A ed egli o qualcun altro nel team sviluppa l'estensione B, dove B dipende da A, il debug di B esegue il codice per A solo se da A si chiama un metodo e se il flag allowDebugging è impostato su true nel file app.json per l'estensione A.
A meno che non si sia specificato l'attributo [NonDebuggable] per metodi e variabili, impostare la proprietà allowDebugging su true per eseguire questo codice. Se, invece, si sono contrassegnati i metodi e le variabili con l'attributo [NonDebuggable], non è possibile sottoporli a debug.
Il valore predefinito del flag allowDebugging è false. Si consiglia di impostare questo flag su true solo se chi ha esteso l'estensione è attendibile. Se allowDebugging è impostato su true, chiunque estenda il codice può accedervi per eseguirne il debug. Se si desidera consentire l'accesso al codice solo ad alcuni individui, è possibile ignorare i criteri delle risorse.
Se il flag allowDebugging è impostato su false, è comunque possibile eseguire il debug del codice in alcuni casi, descritti di seguito:
Qualcuno sarà ancora in grado di visualizzare il codice se si distribuisce un'estensione Visual Studio Code come estensione DEV invece che tramite un cmdlet, nella pagina Gestione estensioni in Business Central o con AppSource.
Gli strumenti esterni personalizzati per AL potrebbero accedere alle informazioni DAL esposte dal debugger ascoltando gli eventi del debugger attivati da Visual Studio Code.
allowDownloadingSource
Quando per questa impostazione si specifica il valore true nel file app.json dell'estensione A, è possibile scaricare il codice sorgente e tutti i file multimediali dell'estensione A, ad esempio selezionando l'opzione Scarica origine nella pagina Gestione estensioni in Business Central. L'estensione A può essere un'estensione PTE o DEV. Il valore predefinito di allowDownloadingSource è false.
includeSourceInSymbolFile
Quando per questa impostazione si specifica il valore true nel file app.json dell'estensione A, il file di simboli scaricato in Visual Studio Code, a cui si accede tramite la funzionalità Download dei simboli, contiene i simboli, il codice sorgente e tutte le altre risorse dell'estensione A. Anche la funzionalità Vai a definizione per visualizzare il codice dipende da questa proprietà. Il valore predefinito di includesourceInSymbolFile è false.
Messaggi di diagnostica del compilatore AL
Quando si compila o si eseguono analizzatori di codice, è possibile visualizzare i messaggi di diagnostica sotto forma di messaggi di errore, di avviso o informativi. Per aiutare a risolvere i problemi, questi messaggi di diagnostica contengono ora un URL per la documentazione aggiuntiva sulla causa e opzioni per la risoluzione.
Nei messaggi di diagnostica, i collegamenti della compilazione o degli analizzatori di codice consentono di visualizzare ulteriore documentazione rilevante per la causa del problema, nonché opzioni per la risoluzione.
Sono disponibili pagine di documentazione per tutti i problemi rilevati dalla diagnostica e collegamenti URL della diagnostica di output del compilatore. Tuttavia, all'inizio, la documentazione sarà molto generica e conterrà principalmente il messaggio. I partner sono invitati a fornire un feedback per indicare i primi argomenti a cui dedicare ulteriore documentazione, nonché a condividere un feedback sui contenuti utili per risolvere i problemi. Su queste basi si spera che la documentazione aumenti nel tempo e che le conoscenze dei partner vengano condivise con suggerimenti e consigli su cause e soluzioni, riducendo il tempo dedicato a ciascuna operazione di diagnostica.
Per esempi e riferimenti, consultare l'articolo corrente Diagnostica del compilatore AL.
Avvio in una società specifica da Visual Studio Code
In un tenant di Business Central possono esistere più società. Quando si esegue il debug o il test di un'app, è spesso preferibile procedere nel contesto di una società specifica. Nelle versioni precedenti di Business Central non era possibile decidere quale società usare all'avvio del client da Visual Studio Code. Sarebbe stato necessario impostare prima la società predefinita nel client.
Il file di configurazione launch.json di Visual Studio Code contiene ora un nuovo parametro startupCompany. Usarlo per specificare la società da usare quando si avvia il client da Visual Studio Code, ad esempio durante l'esecuzione o il debug.
Visualizzazione delle informazioni di SQL Server durante il debug di AL
Può essere difficile comprendere i blocchi del database durante le attività di sviluppo e risoluzione dei problemi nelle sandbox cloud senza accesso SQL diretto. Può essere difficile identificare quali blocchi provengono da AL quando si chiamano metodi come rec.Modify() o rec.FindSet(). Sebbene i blocchi SQL siano ora visibili nel client Web, l'uso a scopo di debug può diventare macchinoso perché richiede un altro browser con un'altra sessione.
Per ovviare a questo inconveniente, la sezione Statistiche database nella finestra Variabili relativa all'esperienza di debug AL di Visual Studio Code è stata ampliata per mostrare i blocchi SQL per la sessione di debug.
Oltre alle statistiche del database e alle istruzioni SQL eseguite per ultime, è anche possibile ottenere informazioni sui blocchi SQL attivi che si verificano durante la sessione in fase di debug. L'elenco viene aggiornato quando si esegue il codice AL. I commit rimuoveranno i blocchi presenti.