Источник:
https://dynamicsuser.net/nav/b/waldo...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!
What
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:
https://code.visualstudio.com/docs/e...oot-workspaces
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:
https://github.com/waldo1001/Cloud.R...are.PowerShell
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!
Источник:
https://dynamicsuser.net/nav/b/waldo...al-development