Al: Multiroot workspace: AL extension tries to compile other projects in the workspace.

[salgiza]

I have created a VS Code workspace that includes an AL project, and a related Azure Function that is used by the AL extension. When I try to debug the Azure extension I get the following error:

error AL1001: Source file '/Path/to/AzureAppFolder/app.json' could not be found
Error: The package could not be created.

It looks like the AL compiler is trying to also compile the AzureApp, and that causes the Azure App compilation to fail.

(If I open the AzureApp folder on its own, it compiles and debugs without problem).

To reproduce it:

• Create an Azure App project.
• Create an AL project.
• Create a VS Code workspace that includes both projects/folders.
• Select the Azure App debug configuration and press F5.
• Instead of compiling and running the Azure App, it tries to compile the Azure App using the AL compiler and fails.

Tested on macOS with version 2.0.56865 of the AL extension.

[kalberes]

We do not support mixing/debugging different project types in a multi-root workspace for now.

[salgiza]

Err.. could it merit an enhancement or suggestion tag?

I mean, I know this is not that much of a problem, but it would be nice if the AL compiler just skipped projects without an app.json (even if it required setting a config param).

[kalberes]

Fine, I will mark that as an enhancement.

[fvet]

@kalberes

In case you manage different extensions as different projects, it seems challenging to apply the same company rules / settings accross these extensions / projects, re-use the company snippets, ... Therefore, we've experienced using VSCode workspaces and have included a 'shared' folder containing our company snippets / templates / code samples / guidelines / wiki / ... This 'shared' folder does not contain an app.json, and thus results in the app.json error as mentioned here.

However, on https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-multiroot-workspaces it is stated:

Grouping a set of disparate project folders into one workspace
It is not mandatory to use only AL-based roots. Different kinds of projects can be mixed ...

Am I misunderstanding the above, telling me that 'mixed' projects should be supported?

[kalberes]

Yes, I think this scenario should be supported. I will mark it as a bug and when I have some time I will fix it.
Thanks.

[jwikman]

Any progress on this @kalberes?
We're having our pipeline yaml files in a root folder in our workspace, giving us this issue.

Just to get rid of the error I've added an app.json to our Pipelines root folder:

{
    "name": "Pipeline - not an app, only to workaround error from the AL Language Extension",
    "publisher": "NoOne",
    "id": "00000000-0000-0000-0000-000000000000",
    "version": "0.0.0.0"
}

I haven't seen any undesired side effect of that yet...

[kalberes]

Not yet, but now that I have accepted it as in progress I will get the bug. If it is not something that would require major redesign of our vscode integration i should fix it for 15.1.

[jwikman]

Great, thanks for the update @kalberes!

[bjarkihall]

Has a design decision been made on the fix?
app.json can't be encapsulated on a multiroot workspace nor in a subdirectory of a repo.
We can suppress errors with @jwikman 's fix but e.g. relative paths in control-addins also seem to just check the root of the current project, instead of the nearest app.json (you get an error if you open the project from another folder level), so is there a way to be more direct on the AL projects' roots?
Hopefully we're not supposed to develop extensions and control-addins in multiple instances of vscode, since it 1. requires you to manually open them (instead of just defining a .code-workspace file) and 2. it's not as compact for related but encapsulated projects, you might want to separate your other build tools and dependencies from the AL compiler, while still having them open in vscode.

Will it be possible to specify the AL project's root path?
Or the other way araound - specify paths for the compiler to ignore (include/exclude paths)?

[fvet]

Somewhat related: Is there any more information available on how to handle multiple AL projects in one VS Code workspace? One of our colleagues told us that at Directions a feature had been demoed showing updates on one app where immediately reflected on dependend apps.

Usecase we've in mind is to create our own 'ISV System Module' project and 'ISV Base Application' project and build other dependend extensions on top of these. Having one VS Code workspace where all extensions reside would allow us to do modications (or at a later stage moving objects) accross these different extensions (system > base > dependend) and package / build / publish all at once from within the same workspace.

[salgiza]

@fvet Just including both projects in the workspace is enough. The AL extension detects that one project depends on another project within the workspace, and when you add a field to a table (for example) in one project, the one that depends on it detects the change immediately, instead of having to publish, download symbols, etc. as before. Furthermore, when you publish the extension that depends on the other, it will publish both to the server if the dependency has changed since the last installed version.

I was in one of the sessions at Directions where they mentioned it, and it worked in the few projects where I've tried it 😄

P.S. That being said, please keep the thread on-topic. I'd like to be able to use workspaces when an AL extension depends on an Azure Function...

[bjarkihall]

Vjeko and Waldo both described their encounters with this issue on NAV TechDays 2019 in all of their sessions:
The AL extension should not pollute sibling workspaces (which can be non-AL related, like AzureApp, WebApp, Powershell scripts in a separate project) with rad.json, complaining over missing app.json, etc.

[kalberes]

This issue has been fixed as far as I know. It should already be available on the internal daily builds. And it will also be available on the next 4.X update of the Al extension package.

[ALGitHubBot]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 38063.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read:
https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/
https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/