Projekte und Arbeitsbereiche konfigurieren
Visual Studio Code bietet die Multi-root workspaces (Arbeitsbereiche mit mehreren Stämmen)-Funktion, mit der Sie verschiedene Projektordner in einem Arbeitsbereich gruppieren können. Die AL Language-Erweiterung unterstützt auch die Multi-root-Funktionalität und ermöglicht Ihnen die Arbeit mit mehreren AL-Ordnern, einschließlich Wurzeln und Projekten in einem Arbeitsbereich.
Befolgen Sie diese Schritte, um gleichzeitig an mehreren verwandten Projekten zu arbeiten:
Wählen Sie auf der Registerkarte Datei von Visual Studio Code die Option Ordner dem Arbeitsbereich hinzufügen ... aus.
Speichern Sie die Arbeitsbereichsdatei, wenn Sie sie erneut öffnen möchten.
Durch diese Schritte wird eine .code-workspace-Datei erstellt, die ein Array von Ordnern mit absoluten oder relativen Pfaden enthält. Wählen Sie die relativen Pfade aus, wenn Sie Ihre Arbeitsbereichsdateien freigeben möchten.
Ändern Sie die Einstellungen Ihrer Dateien mithilfe des Editors Einstellungen. Sie können Ihre Benutzereinstellungen, globalen Arbeitsbereichseinstellungen oder Einstellungen für einzelne Ordner ändern.
Es ist nicht zwingend erforderlich, dass nur AL-basierte Wurzeln verwendet werden. Verschiedene Arten von Projekten können gemischt werden, und jedes AL-Projekt hat seine Konfigurationswerte für folgende Einstellungen:
al.packageCachePath
al.enableCodeAnalysis
Mit der Einstellung al.packageCachePath können Sie den Pfad zu einem Ordner angeben, der als Cache für die von Ihrem Projekt verwendeten Symboldateien verwendet wird. Dies kann unter Benutzereinstellungen, ArbeitsbereichEinstellungen oder Projekteinstellungen angegeben werden.
Mit der Einstellung al.enableCodeAnalysis können Sie das Ausführen von Codeanalysatoren für Ihr Projekt aktivieren. Dies kann genauso unter Benutzereinstellungen, ArbeitsbereichEinstellungen oder Projekteinstellungen angegeben werden.
Eine Projektreferenz in einem AL-basierten Arbeitsbereich wird als Abhängigkeit in der Datei App.json festgelegt und ist als Projekt im Arbeitsbereich vorhanden. Von einer Projektreferenz gibt es keine spezielle visuelle Darstellung.
Eine Projektreferenz besteht aus der vollständigen ID, Name, Herausgeber und Version eines vorhandenen Projekts im Arbeitsbereich. Dies steht im Gegensatz zu einer Anwendungsreferenz, bei der es ausreichend ist, eine minimale Version anzugeben. Wenn Sie Arbeitsbereiche mit mehreren Projekten verwenden, und Name oder Herausgeber einer Erweiterung im Arbeitsbereich verändern, müssen die Abhängigkeiten in der Datei app.json mit dem neuen Namen und Herausgeber aktualisiert werden, es können sonst Probleme mit der Referenzauflösung auftreten.
Im folgenden Beispiel definiert das Projekt mit dem Namen Leaf zwei Abhängigkeiten zu den Projekten Middle und Root. Da sowohl Root als auch Middle Projekte im Arbeitsbereich sind, gelten sie als Projektreferenzen.
Das Arbeiten mit Projektreferenzen bietet den Vorteil, dass die Symbole für eine Projektreferenz nicht heruntergeladen werden müssen. Sie sind als Symbole für das Referenzprojekt vorhanden und werden aufgelöst, wenn sie verändert werden. Beispiel: Wenn Sie einer Codeunit im Projekt Root eine neue Methode hinzufügen und auf die Codeunit im Projekt Leaf verweisen, wird die Methode automatisch aufgelöst, wenn Sie mit dem Projekt Leaf arbeiten.
Wenn ein Projekt mit STRG+UMSCHALT+B erstellt wird, geschieht Folgendes:
Die .app-Datei wird in den Ordner .alpackages aller Projekte kopiert, die davon abhängig sind.
Alle Projektreferenzen, die möglicherweise „ungültig“ sind, werden ebenfalls erstellt.
Wenn die Referenzauflösung nicht mehr funktioniert, werden die Referenzen durch das Erstellen der Projektreferenz und das erneute Initialisieren des Arbeitsbereichs mit der Option Fenster neu laden aufgelöst.
Wenn ein Projekt in einen Arbeitsbereich geladen wird, versucht es, alle eigenen Projektreferenzen als transitiven Vorgang zu laden. Funktionen wie IntelliSense und Mauszeiger darüber bewegen sind während des Ladens des Projekts nicht verfügbar. Je nach Anzahl der Projektreferenzen und Dateien im Projekt kann dieser Vorgang viel Zeit in Anspruch nehmen.
Der Benutzer wird mit den standardmäßigen Visual Studio Code-Benachrichtigungsfenstern des Codefortschritts über den aktuellen Status informiert, wenn das Projekt in den Arbeitsbereich geladen wird. Die Benachrichtigungen können geschlossen werden, aber sie hören nicht damit auf, ein Projekt zu laden. Wenn der Benutzer woanders auswählt oder das aktive Projekt verändert, wird das Laden des vorherigen Projekts abgebrochen und stattdessen das neu ausgewählte aktive Projekt geladen. Ein Projekt kann geladen werden, indem es aktiviert wird oder indem eine .al-Datei oder die Projektdatei App.json geöffnet wird. Sobald ein Projekt geladen ist, bleibt es geladen, bis der AL-Sprachserver aktiv ist oder der Befehl Fenster neu laden mit STRG+R ausgelöst wird.
Projekte, die noch nicht in den Arbeitsbereich geladen wurden, werden mit dem Buchstaben N markiert.
Mit der Einführung von Projektreferenzen hat sich die Veröffentlichungslogik in einem Arbeitsbereich verändert. Beim Veröffentlichen, entweder mit STRG+F5 oder RAD-Veröffentlichen mit ALT+STRG+F5 wird ein Satz aller Projekte veröffentlicht, die sich mit der Definition eines Startprojekts geändert haben. Das Startprojekt ist immer das aktive Projekt.
Ein Projekt gilt als verändert, wenn sich eines seiner Anwendungsobjekte dahingehend geändert hat, dass sich das Anwendungsobjekt bereits in rad.json befindet oder in rad.json enthalten sein wird, sobald das Projekt erstellt wurde. Das bedeutet, wenn Sie ein Anwendungsobjekt ändern, es speichern und dann Visual Studio Code schließen, ohne das Projekt zu erstellen, wird rad.json nicht aktualisiert und das Projekt wird nicht als „ungültig“ betrachtet.
Beispielsweise hängt in einem Arbeitsbereich mit drei Projekten Leaf, Middle und Base Leaf von Middle und Base ab, und Middle hängt von Base ab, wie im folgenden Diagramm dargestellt:
Wir nehmen an, dass:
Alle drei Projekte: Leaf, Base und Middle haben sich geändert.
Das Projekt Leaf ist das aktuell veröffentlichte Projekt.
Dann werden alle drei Projekte: Base, Middle und Leaf Teil des Sets sein, das veröffentlicht wird.
In einem Szenario, in dem sich Middle nicht geändert hat, aber Leaf noch immer das Startprojekt ist, werden nur noch Base und Leaf veröffentlicht.
Eine neue Datei wird erstellt, um die aufgerufenen Set-Abhängigkeiten mit dem Namen *.dep.app zu packen. Wenn die Veröffentlichung des Abhängigkeitssatzes erfolgreich ist, wird diese Datei auf den Server übertragen und gelöscht.
Obwohl es sich bei der Serververöffentlichung um einen internen Schritt handelt, wirkt sie sich auf die Abhängigkeitsveröffentlichung aus, und es ist hilfreich, sie zu kennen.
Zum Beispiel in einem Arbeitsbereich mit zwei Projekten: Leaf ist abhängig von Base, und External und Indirekt sind Projekte außerhalb des Arbeitsbereichs, wie unten gezeigt:
Wir nehmen an, dass:
Es existiert ein Arbeitsbereich mit Leaf und Base Arbeitsbereichprojekten.
Base ist veröffentlicht.
Auf dem Server Base sind Leaf, External und Indirekt bereits installierte Apps.
Folgende Dinge geschehen auf dem Server:
Alle Apps, die von Base abhängen, werden deinstalliert, einschließlich der Abhängigkeiten External und Indirekt.
Alle anderen Apps, die direkt von Base abhängen und nicht im globalen Bereich veröffentlicht werden – in diesem Fall Leaf und External – sind unveröffentlicht.
Base wird deinstalliert, unveröffentlicht und dann veröffentlicht.
Leaf und External werden veröffentlicht, installiert und dann mit der neu veröffentlichen Base kompiliert. Wichtig zu beachten ist, dass die App External auch veröffentlicht wird.
Die Datei launch.json verfügt über eine dependencyPublishingOption mit den folgenden Optionen, um zu steuern, wie Abhängigkeitsveröffentlichungen auf dem Server durchgeführt werden:
Standard
- Die Veröffentlichung von Abhängigkeiten wird angewendet.
Ignorieren
- Veröffentlichung von Abhängigkeiten wird ignoriert. Diese Einstellung sollte vorsichtig verwendet werden. Siehe Hinweis unten.
Streng
- Die Abhängigkeitsveröffentlichung schlägt fehl, wenn installierte Apps vorhanden sind, die vom Startprojekt abhängig sind.
Mit der Einstellung Ignorieren wird nur Leaf veröffentlicht gegen das, was bereits auf dem Server für Middle und Base veröffentlicht wurde. Wenn eine Änderung an Base vorgenommen wurde, die Leaf beschädigen würde, obwohl die lokale Kompilierung passieren würde, schlägt die Serverkompilierung in diesem Szenario fehl. Der Vorteil dieser Option besteht darin, Veröffentlichungszeit zu gewinnen, wenn es sich bei Base um ein großes Projekt handelt. Nehmen wir an, dass Base veröffentlicht wurde, dann bleiben Middle und Leaf auf dem Server unberührt. Nur Runtime-Fehler zeigen, wenn Base Middle und Leaf beschädigt haben.
Verwenden Sie den Befehl AL: Publish Vollständige Abhängigkeitsstrukturansicht für aktives Projekt, der ein Projektabhängigkeitsdiagramm im Arbeitsbereich durchläuft und alle erforderlichen Projekte installiert, sofern vorhanden sind noch nicht auf dem NST-Server bereitgestellt, um unnötige manuelle Arbeit zu vermeiden. Verwenden Sie die Tastenkombinationen STRG+UMSCHALT+P oder SHIFT+ALT+W, um den Befehl zu suchen. Dadurch wird die richtige Reihenfolge berechnet, in der die Abhängigkeiten des aktuellen Projekts kompiliert und veröffentlicht werden, und sie werden mit der aus dem aktuellen aktiven Projekt ausgewählten Option „launch.json“ veröffentlicht.
Es werden nur Projekt‑ und App-Referenzen durchgegangen, die vom Arbeitsbereich abgedeckt werden. Wenn das bereitgestellte AL-Projekt Abhängigkeiten zu Apps hat, die nicht im Arbeitsbereich enthalten sind, müssen diese dennoch vorhanden sein oder im Voraus manuell bereitgestellt werden.
Wenn die Einstellung al.incrementalBuild in Arbeitsbereichen mit Referenzen von Projekt zu Projekt auf „true“ gesetzt ist, erfolgen alle Auflösungen aus dem referenzierten Projekt und nicht aus einer App im Ordner \packagecache, was die Erstellungszeit verlängert.