Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 21.02.2020, 11:11   #1  
Blog bot is offline
Blog bot
23,159 / 786 (73) +++++++
Регистрация: 28.10.2006
waldo: Multi-root Workspaces in VSCode for AL Development

Youmight have figured – I’m a VSCode fanboy. One of many. You might rememberthe session I did on NAVTechDays 2017 (Rock ‘nRoll with VSCode), where I dove quite a bit intothe possibilities this great tool comes with. But I didn’t talk about the concept of “Multi-root Workspaces”: an ability of VSCodefor you to work on multiple“projects” at the same time, in one environment.

2years later, last NAVTechDays, I talkedabout Dependencies quite a lot, and when you thinkof it – in terms of dependencies in AL for BusinessCentral, these “Multi-root Workspaces” might make a lot of sense, because when youhave all these apps, you might have to work on multiple apps at the sametime.

Evenmore, in that same video, you’ll see that I ALWAYS have at least 2 apps: anapp, and its test-app. So in terms of“Test Driven Development” (a methodology I believe is indispensable), you will always have an app,and a dependent app, and you will always work on both apps at the sametime. So – “Multi Root” to therescue!


Well,the concept of “multi-root workspaces” is actually most simplyexplained by: opening multiple projects (workspaces) at the same time, to beable to work on multiple pieces of software at the same time. Or in terms of Business Central: to work (compile, publish, develop, …) on multipleapps at the same time.

Theconcept is quite well explained on the docs-page for VSCode:

VSCode Extensions

The onedownside of this concept is that not every VSCode extension might be ready in aMulti-root environment. In fact, it tooka while to get my own extension (the CRS AL Language Extension) ready forMulti-root workspaces (and there still might be issues with it ;-)).

Samefor Microsoft’s AL Language Extension. It took a while – but just imagine:
  • When you’re working on extension A, from which Extension B is dependent – Extension B will recognize the symbols of Ext A without even having to create (compile) an app file – just because Ext B is in your Multi Root Workspace
  • When you’re debugging, you’re able to go to definition into al-files of other apps you’re debugging – not just the only-one-level-dal-files. Just because you have the dependent app in your workspace.
  • Whenever you compile a main app, the symbol files of the dependent apps are updated with the new version of the main app. Just because it’s in your multi-root workspace.
All this is already possible!

Andthat’s what a real“Multi-root” experience can give you – and why I think we shouldalways look into this. It makes all thesense in the world – in a world with “lots” of apps and dependencies,to work on them simultaneously. And I’msure – if you’re not yet doing it – it can speed up your development processeven more!

In Practice

May be afew screenshots that can show you how it could look like.

In thiscase, I’m actually working on 7 apps at the same time, with all of them having a test-app as well (which we use forunit-testing). The last app is theintegration-test-app.

How does it determine what app I’m working in?

Well,simply by the active editor. If I would want to compileand publish the BASE-App, I would open one of the files of that app, and simply press F5.

Symbols constantly updated over all workspaces

In mycase, the BASE App is a library-app for all other apps. And if I would simply start coding in thatBASE-App, like this useless codeunit:

Iwould – without even compiling my app – be able to code against this in any app that isdependent from that BASE-App:

Basicallymeaning: I can code against all apps at the same time, without evendownloading/updating symbols, or compiling or publishing.

Updating Symbols

Even,when you hit compile, you’ll notice that the symbol files in the.alpackages-folder are updated for all apps that depend from the app thatyou’re compiling. Very cool!

Can I control this a bit?

Well –you do have the “dependencyPublishingOption” in the launch.json,which has 3 options:
  • Default: set dependency publishing will be applied
  • Ignore: Only the current project is published, dependencies are ignored.
  • Strict: Publishing will fail if the project has apps that not part of the workspace and depend on it
Ilike the default setting – something it takes a little longer to include alldependencies in the compile – but at least you’re checking all dependencies ..So that must be good ;-). But, in some cases – especially in case ofbig apps with many objects – you might want to avoid unnecessary recompiles ofdependent apps.. .

Does this mean everything needs to be in one (Git) repository?

No! VSCode is smart enough to handle multipleworkspaces at the same time. In case ofthe screenshot above – and as mentioned in a recent webcast I did about handling dependencies inDevOps – all my apps are in separate repos, together with theirTest-apps. So in case of the screenshot,it would be a collection of about 8 GIT repositories. When you switch to the “SourceControl” window, VSCode clearly shows all states of the repositories, likeyou see here in the screenshot:

You cansimply see when repos need attention (new/modified/delete files), whatbranches, and what the synchronization state is. From this window, you can obviously alsochange branches, sync, and so on.. .

Thereis more …

AndI have more for you. To make working inmultiple workspaces more easy, I’m working on a set of scripts, which you findon my PowerShell repository:

Iwill maintain a set of scripts in the folder ./PSScripts/NAV Extensionsv2/MultiRootWorkspaces/ . Today, I have foreseen:
  • LaunchJson_CopyToAll.ps1: If you change docker image or whatever – this script will simply copy one launch.json to all other workspaces so that you will easily publish other dependent apps to the same sandbox
  • Symbol_Cleanup.ps1: This script removes all symbol files – just imagine when you want to publish against another version (localization, insider, ..), you can simply cleanupt all files and even invoke the next script, which will …
  • Symbol_Download.ps1: This script will download as many symbols as possible for all workspaces that are available in your multiroot workspace.
I’m alsoworking on a “CompileAll” script – would be nice to have one scriptthat figures our the dependency tree (Ialready got that one), and invoke start compiling all the apps – and – maybe – if possible – even starts publishing them to the server instance ;-). Let’s see where we end up with that one ;-).

Theremight be issues with the scripts – they are brand new – but please, use,abuse .. and contribute ;-).

Enjoygoing Multi-root!

Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
waldo: VSCode & Snippets Blog bot NAV: Blogs 0 20.01.2020 14:11
waldo: AL Extension Pack for VSCode Blog bot NAV: Blogs 0 02.07.2019 10:11
waldo: AL with VSCode: IntelliSense Fix Blog bot NAV: Blogs 0 22.03.2018 10:11
waldo: AL with VSCode: ExportToNewSyntax Blog bot NAV: Blogs 0 07.08.2017 04:17
waldo: Microsoft Dynamics NAV 2017 – what’s really new? Blog bot NAV: Blogs 0 13.10.2016 05:22
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 00:47.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.