プロジェクトおよびワークスペースの構成
Visual Studio Code は、マルチルート ワークスペース機能を提供します。これにより、異なるプロジェクト フォルダーを 1 つのワークスペースにグループ化することができます。 また、AL 言語拡張モジュールではマルチルート機能がサポートされており、1 つのワークスペース内のルートやプロジェクトを含む、複数の AL フォルダーを使用できます。
次の手順に従うと、関連する複数のプロジェクトで同時に作業を行うことができます。
Visual Studio Code のファイル タブで、ワークスペースへのフォルダの追加... を選択します。
ワークスペース ファイルを再び開く予定がある場合は、そのファイルを保存します。
これらの手順により、絶対パスまたは相対パスを持つフォルダーの配列を含む、code-workspace ファイルが作成されます。 ワークスペース ファイルを共有する場合は、相対パスを選択します。
設定エディターで、ファイルの設定を変更します。 ユーザー設定、グローバル ワークスペースの設定、または個々のフォルダー設定を変更できます。
使用できるのは AL ベースのルートのみではありません。 複数の種類のプロジェクトを組み合わせることもできます。AL の各プロジェクトでは、次の設定に値を構成することになります。
al.packageCachePath
al.enableCodeAnalysis
al.packageCachePath 設定では、プロジェクトで使用するシンボル ファイルのキャッシュとして機能するフォルダーへのパスを指定します。 このパスは、ユーザー設定、ワークスペース設定、またはプロジェクト設定で指定できます。
al.enableCodeAnalysis 設定では、プロジェクトでのコード アナライザーの実行を有効化できます。 こちらも、ユーザー設定、ワークスペース設定、またはプロジェクト設定で指定できます。
AL ベースのワークスペースでは、プロジェクト参照は依存関係として app.json ファイルに定義され、ワークスペースにプロジェクトとして配置されます。 プロジェクト参照を表す特別な画像はありません。
プロジェクト参照は、ワークスペースに存在するプロジェクトの ID、名前、公開元、バージョンで構成されます。 これに対し、アプリケーション参照ではミニマル バージョンを指定できます。 複数のプロジェクトを含むワークスペースを使用しており、ワークスペース内の拡張機能の名前または公開元を変更した場合、app.json ファイルの依存関係を新しい名前と公開元で更新する必要があります。そうすることで、参照解決に関する問題を回避することができます。
次の例では、Leaf という名前のプロジェクトに、Middle プロジェクトと Root プロジェクトへの 2 つの依存関係が定義されています。 そのため、Root と Middle はいずれもワークスペースに存在するプロジェクトであり、プロジェクト参照と見なされます。
プロジェクト参照の使用には、プロジェクトの参照に必要なシンボルのダウンロードが不要になるというメリットがあります。 プロジェクト参照は、参照するプロジェクトのシンボルとして存在し、プロジェクトの変更時には解決が行われます。 たとえば、Root プロジェクトの codeunit に新しいメソッドを追加し、そこから Leaf プロジェクトの codeunit を参照する場合、Leaf プロジェクトにタッチする際にこのメソッドが自動的に解決されます。
プロジェクトを Ctrl+Shift+B キーで作成すると、次の処理が行われます。
.app ファイルが、依存関係にあるすべてのプロジェクトの .alpackages フォルダーにコピーされます。
「dirty」になり得るすべてのプロジェクト参照も作成されます。
参照の解決が機能を停止すると、プロジェクト参照の構築と、ワークスペースの再初期化が、Reload Window 解決参照を使用して行われます。
プロジェクトがワークスペースに読み込まれる際、そのすべてのプロジェクト参照の読み込みが推移処理として行われます。 プロジェクトの読み込み中、IntelliSense やポイントなどの機能は使用できません。 プロジェクトに含まれるプロジェクト参照やファイルの数が多い場合は、この処理に時間がかかります。
プロジェクトをワークスペースに読み込む際、Visual Studio Code の現在の進捗状況を通知する標準的なダイアログが表示されます。 通知は消すことができますが、プロジェクトの読み込みを停止することはできません。 ユーザーが別のワークプレースを選択するか、アクティブなプロジェクトを変更すると、プロジェクトの読み込みがキャンセルされ、新しく選択したアクティブなプロジェクトの読み込みが開始されます。 プロジェクトはアクティブにするか、.al ファイルを開くか、app.json プロジェクト ファイルを開くことで、読み込みを開始できます。 プロジェクトは一度読み込まれると、AL 言語サーバーがアクティブになるまで、またはReload Window コマンドが Ctrl+R キーを使用してトリガーされるまで、その状態を維持します。
ワークスペースに読み込まれていないプロジェクトは、N の文字で装飾されます。
プロジェクト参照が導入されたことで、ワークスペースの公開ロジックが変更されています。 Ctrl+F5 キーで公開するか、Alt+Ctrl+F5 キーを使用して RAD 公開を行うと、スタートアップ プロジェクトを定義して変更を行ったすべてのプロジェクトの公開が一括で行われます。 スタートアップ プロジェクトは常にアクティブ プロジェクトになります。
プロジェクトは、そのアプリケーション オブジェクトが 1 つでも変更されると (つまり、アプリケーション オブジェクトが rad.json に存在するか、プロジェクトの作成後に rad.json に存在すると)、変更されたと見なされます。 つまり、アプリケーション オブジェクトを変更し、保存して、プロジェクトを作成することなく Visual Studio Code を閉じた場合、rad.json は更新されないため、プロジェクトが「dirty」と判断されることはありません。
たとえば、次の図に示すとおり、あるワークスペースに Leaf、Middle、Base の 3 つのプロジェクトが含まれていて、Leaf は Middle と Base に依存し、Middle は Base に依存していたとします。
次を仮定します。
Leaf、Base、Middle のプロジェクトがすべて変更された。
Leaf は現在のプロジェクトであり、公開されている。
この場合、Base、Middle、Leaf の 3 つのすべてのプロジェクトが一括で公開されます。
Middle は変更されていないが、Leaf が依然スタートアップ プロジェクトである場合は、Base と Leaf が公開されます。
依存関係をまとめてパッケージ化するために、*.dep.app と呼ばれる新しいファイルが作成されます。 このファイルはサーバーに転送されますが、依存関係のセットが公開に成功すると削除されます。
サーバー公開は内部で行われますが、依存関係の公開に関連があるため、理解しておくと役に立ちます。
たとえば、ワークスペースで Leaf プロジェクトが Base プロジェクトに依存し、ワークスペースの外部に External と Indirect の 2 つのプロジェクトが存在するとします (下の図を参照)。
次を仮定します。
ワークスペースに Leaf と Base のワークスペース プロジェクトが存在する。
Base は公開済みである。
Base、Leaf、External、Indirect のアプリはサーバーにインストール済みである。
サーバーでは次の事象が発生します。
Base に依存するすべてのアプリが、External と Indirect の依存関係を含めてアンインストールされる。
Base に直接依存し、グローバル スコープで公開されていない他のすべてのアプリ (この例の場合は Leaf と External) が非公開になる。
Base がアンインストールされ、非公開になった後に発行される。
Leaf と External は公開され、インストールされた後に、新しく公開された Base にコンパイルされる。 ここで、External アプリも公開されることに注意が必要です。
launch.json ファイルで dependencyPublishingOption に次のオプションを設定し、サーバーでの依存関係の公開の実行方法を制御することができます。
既定
- 依存関係を公開する設定が適用されます。
無視
- 依存関係の公開が無視されます。 この設定の使用には注意が必要です。 下記の説明を参照してください。
厳密
- スタートアップ プロジェクトに依存するアプリがインストールされると、依存関係の公開が失敗します。
Ignore を設定すると、Middle と Base のサーバーで既に公開されているものに対して、Leaf だけが公開されます。 Base を変更したことによって Leaf が破損した場合、ローカルでのコンパイルが成功しても、サーバーのコンパイルが失敗します。 このオプションには、Base プロジェクトが大規模な場合に、公開時間が得られるというメリットがあります。 Base が公開されても、Leaf や Middle にはサーバーでの処理が必要ありません。 Base によって Middle と Leaf が破損した場合の実行エラーの表示のみが行われます。
AL: Publish full dependency tree for active project コマンドを使用すると、ワークスペース内のプロジェクト依存関係グラフを走査し、必要なプロジェクトが NST サーバーに展開されていない場合にインストールが行われるため、手動で作業する必要がなくなります。 このコマンドは Ctrl+Shift+P キー、または Shift+Alt+W キーで使用できます。 これにより、コンパイルの順序が正しく計算され、現在のプロジェクトの依存関係が、現在アクティブなプロジェクトで選択された launch.json を使用して公開されます。
ワークスペースに含まれるプロジェクトおよびアプリ参照だけが走査されます。 展開する AL プロジェクトに、ワークスペースに含まれないアプリへの依存関係が存在する場合は、展開後も依存関係を保持するか、あらかじめ手動で展開する必要があります。
プロジェクトを含むワークスペースで、プロジェクト参照への al.incrementalBuild 設定を true にセットすると、すべての解決が \packagecache フォルダーのアプリからではなく、参照プロジェクトから行われるため、構築時間が拡張されます。