Configurazione di progetti e aree di lavoro
Visual Studio Code offre la funzionalità per aree di lavoro con più radici che consente di raggruppare diverse cartelle di progetto in una sola area di lavoro. Anche l'estensione AL Language supporta la funzionalità con più radici e consente di lavorare con più cartelle AL che includono radici e progetti all'interno di una sola area di lavoro.
Esaminare i seguenti passaggi per lavorare contemporaneamente su diversi progetti correlati.
Nella scheda File di Visual Studio Code, scegliere Aggiungi cartella all'area di lavoro....
Salvare il file dell'area di lavoro se si prevede di aprirlo di nuovo.
In questo modo, si crea un file code-workspace contenente una matrice di cartelle con percorsi assoluti o relativi. Se si vuole condividere i file dell'area di lavoro scegliere i percorsi relativi.
Modificare le impostazioni dei file nell'editor Impostazioni. È possibile modificare le impostazioni utente, le impostazioni globali dell'area di lavoro o le impostazioni delle singole cartelle.
Non è obbligatorio usare solo radici basate su AL. È possibile combinare diversi tipi di progetti e ogni progetto AL avrà propri valori di configurazione per le seguenti impostazioni:
al.packageCachePath
al.enableCodeAnalysis
L'impostazione al.packageCachePath consente di specificare il percorso di una cartella che fungerà da cache per i file di simboli usati dal progetto. È possibile specificarlo in Impostazioni utente, Impostazioniarea di lavoro o Impostazioni progetto.
L'impostazione al.enableCodeAnalysis consente di abilitare l'esecuzione di analizzatori di codice sul proprio progetto. Analogamente, è possibile specificarlo in Impostazioni utente, Impostazioniarea di lavoro o Impostazioni progetto.
Un riferimento al progetto in un'area di lavoro basata su AL è definito come dipendenza nel file app.json ed esiste come progetto nell'area di lavoro. Non esiste una rappresentazione visiva speciale di un riferimento al progetto.
Un riferimento al progetto è composto da ID, nome, editore e versione completi di un progetto esistente nell'area di lavoro. Si differenzia da un riferimento all'applicazione in cui è sufficiente specificare una versione minima. Se si usano aree di lavoro con più progetti e si modifica il nome o l'editore di un'estensione nell'area di lavoro, è necessario aggiornare le dipendenze nel file app.json in base al nuovo nome** e all'editore o si potrebbero verificare problemi con la risoluzione dei riferimenti.
Nell'esempio seguente, il progetto denominato Leaf definisce due dipendenze ai progetti Middle e Root. Poiché sia Root sia Middle sono progetti nell'area di lavoro, sono considerati riferimenti al progetto.
Il vantaggio di lavorare con riferimenti al progetto è che non è necessario scaricare i simboli per un riferimento al progetto. Sono presenti come simboli per il progetto di riferimento e verranno risolti man mano che vengono modificati. Ad esempio, se si aggiunge un nuovo metodo a una codeunit nel progetto Root e si fa riferimento alla codeunit nel progetto Leaf, il metodo si risolverà automaticamente quando si tocca il progetto Leaf.
Quando si crea un progetto con CTRL+MAIUSC+B, si verifica quanto segue:
Il file .app viene copiato nella cartella .alpackages di tutti i progetti che dipendono da esso.
Vengono creati anche tutti i riferimenti al progetto che potrebbero essere modificati.
Se la risoluzione dei riferimenti smette di funzionare, la creazione del riferimento al progetto e la reinizializzazione dell'area di lavoro mediante Ricarica finestra risolvono i riferimenti.
Quando si carica un progetto in un'area di lavoro, si tenta di caricare tutti i relativi riferimenti al progetto come operazione transitiva. Durante il caricamento di un progetto, funzionalità come IntelliSense e il passaggio del mouse non sono disponibili. A seconda del numero di riferimenti al progetto e di file nel progetto, questa operazione può richiedere molto tempo.
Quando si carica il progetto nell'area di lavoro, l'utente riceve le notifiche attraverso le finestre di dialogo di notifica avanzamento di Visual Studio Code standard. È possibile chiudere le notifiche, ma non è possibile interrompere il caricamento di un progetto. Se l'utente seleziona altro o modifica il progetto attivo, si annulla il caricamento del progetto precedente e si avvia il caricamento del progetto attivo appena selezionato. È possibile caricare un progetto rendendolo attivo, aprendo un file .al o aprendo il file di progetto app.json. Un progetto caricato rimane tale finché rimane attivo il server in linguaggio AL o finché non viene attivato il comando Ricarica finestra usando CTRL+R.
I progetti non caricati nell'area di lavoro sono decorati con la lettera N.
Con l'introduzione dei riferimenti al progetto, la logica di pubblicazione in un'area di lavoro è cambiata. La pubblicazione con CTRL+F5 o la pubblicazione RAD con ALT+CTRL+F5 eseguirà una pubblicazione impostata di tutti i progetti cambiati con la definizione di un progetto di avvio. Il progetto di avvio è sempre il progetto attivo.
Un progetto viene considerato modificato se uno qualsiasi degli oggetti applicazione è cambiato nel senso che l'oggetto applicazione è già presente nel file rad.json o lo sarà una volta creato il progetto. Ciò significa che se si cambia un oggetto applicazione, lo si salva e si chiude Visual Studio Code senza compilare il progetto, il file rad.json non si aggiornerà e il progetto non sarà considerato modificato.
Ad esempio, in un'area di lavoro con tre progetti, ovvero Leaf, Middle e Base: Leaf dipende da Middle e Base, mentre Middle dipende da Base come mostrato di seguito:
Supponendo che:
Tutti e tre i progetti Leaf, Base e Middle sono cambiati.
Il progetto Leaf è il progetto corrente che viene pubblicato.
Quindi, tutti e tre i progetti, Base, Middle e Leaf faranno parte del set che verrà pubblicato.
In uno scenario in cui Middle non è cambiato e Leaf è ancora il progetto di avvio, solo Base e Leaf verranno pubblicati.
Si crea un nuovo file per creare un pacchetto delle dipendenze impostate chiamate *.dep.app. Questo file viene trasferito al server e viene eliminato se la pubblicazione del set di dipendenze si svolge senza problemi.
Sebbene la pubblicazione sul server sia un passaggio interno, è bene sapere che influisce sulla pubblicazione delle dipendenze.
Ad esempio, in un'area di lavoro con due progetti Leaf dipende da Base, mentre External e Indirect sono progetti esterni all'area di lavoro, come mostrato di seguito:
Supponendo che:
Esiste un'area di lavoro con Leaf e Base come progetti dell'area di lavoro.
Base viene pubblicato.
Sul server Base, Leaf, External e Indirect sono app già installate.
Sul server si verifica quanto segue:
Tutte le app che dipendono da Base verranno disinstallate, incluse le dipendenze External e Indirect.
Viene annullata la pubblicazione di tutte le altre app che dipendono direttamente da Base e non sono pubblicate nell'ambito globale, in questo caso Leaf ed External.
Base viene disinstallato, ne viene annullata la pubblicazione e quindi viene pubblicato.
Leaf e External verranno pubblicati, installati e quindi compilati rispetto al progetto Base appena pubblicato. È importante notare che verrà anche pubblicata l'app External.
Per controllare come si svolge la pubblicazione delle dipendenze sul server, il file launch.json ha un'impostazione dependencyPublishingOption con le seguenti opzioni:
Predefinito
- Viene applicata la pubblicazione della dipendenza impostata.
Ignora
- La pubblicazione della dipendenza è ignorata. Usare questa impostazione con cautela, vedere la nota di seguito.
Rigorosa
- La pubblicazione delle dipendenze non riesce se sono presenti app installate che dipendono dal progetto di avvio.
Con l'impostazione Ignora solo Leaf sarà pubblicato rispetto a ciò che è già stato pubblicato sul server per Middle e Base. Se si è apportata una modifica al progetto Base che interrompe Leaf, anche se la compilazione locale riesce, la compilazione sul server ha esito negativo in questo scenario. Il vantaggio di usare questa opzione è ottimizzare il tempo di pubblicazione quando il progetto Base è di grandi dimensioni. Presupponendo che il progetto Base sia pubblicato, i progetti Leaf e Middle rimangono inalterati sul server. Solo gli errori di runtime rivelano se Base ha interrotto Middle e Leaf.
Per rimuovere il lavoro manuale non necessario, usare il comando AL: Publish full dependency tree for active project, che attraverserà un grafico delle dipendenze del progetto nell'area di lavoro e installerà tutti i progetti richiesti se questi non sono già distribuiti al server NST. Trovare il comando usando CTRL+MAIUSC+P o usando la scelta rapida da tastiera MAIUSC+ALT+W. In questo modo, si calcola l'ordine corretto in cui compilare e pubblicare le dipendenze del progetto corrente e pubblicarle usando l'opzione launch.json selezionata dal progetto attivo corrente.
Si attraverseranno solo i riferimenti a progetti e app coperti dall'area di lavoro. Se il progetto AL distribuito ha dipendenze da app non incluse nell'area di lavoro, dovranno essere presenti o distribuite manualmente in anticipo.
Se l'impostazione al.incrementalBuild è impostata su true nelle aree di lavoro con riferimenti da progetto a progetto, tutte le risoluzioni avvengono dal progetto a cui si fa riferimento e non da un'app nella cartella \packagecache, ottimizzando il tempo di compilazione.