Remove redundant .alpackages folders

[christianbraeunlich]

With multiple Apps for one project it would make sense to make use of the al.packageCachePath setting.
A value such as ../.alpackages would result in only one .alpackages directory for the entire project.

What do you think? 🦦

[waldo1001]

I like it - I'm going to give this a try!

[tscottjendev]

Been using this for a while now (2+ years) and works great. Except, some functions of VSC extensions have issues with the .alpackages folder not being found. Sorry @waldo1001 I am looking at you waldo1001/crs-al-language-extension#228 😜. You are not the only one but just the one I can remember.

I also move my ruleset to the workspace level so it covers all my projects and then, if a specific project needs something more than the defaults you can add put a ruleset in the project folder and reference the workspace work ruleset file with includedRuleSets entry. Then add the ruleset path to the folder settings for that project. https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-rule-set-syntax-for-code-analysis-tools

[christianbraeunlich]

Thanks for sharing your experience @tscottjendev that is awesome! What I struggle with also is that some extensions simply don't support this behavior. I used to put the ruleset in the project-root folder aswell but for some pipeline complexity I can not remember I let go off it.

You want to start a new discussion about the RuleSet file and the includedRuleSets entry? I think that is be very valuable 🦦

[waldo1001]

Been using this for a while now (2+ years) and works great. Except, some functions of VSC extensions have issues with the .alpackages folder not being found. Sorry @waldo1001 I am looking at you waldo1001/crs-al-language-extension#228 😜. You are not the only one but just the one I can remember.

Interesting.
So what exactly is the problem?

[tscottjendev]

@waldo1001 the details should be in the issue I linked but basically the packagecachepath is missing a "".

[waldo1001]

Oops 🤪. I'll have a look!

[fvet]

Since I'm currently mainly working on product development (few customer projects), I went one step further and set the packageCachePath (in my personal settings) to a fix local folder, which is kind of my 'central repository' of all apps. This eliminates dozens of duplicate apps (both MS and ISV apps) and avoids having to download symbols for every single app (one app = one repo) of our product suite.

Had some conflicts though to get this working combined with the baselinePackageCachePath used for AppSourceCop.
microsoft/AL#6961

[christianbraeunlich]

I like where this is going! You are absolutely right. In the end its the whole project meaning that if there are multiple apps that all together would result in an entire product, the packageCachePath should be based on the root-level of that entire projects. Thanks for sharing the Issue - that's awesome!

[christianbraeunlich]

Been using this now for quite a while now. With a fixed path, as you already mentioned and I think that this can be created as a Best Practice. So as long as the .code-workspace file is located in the root directory of the project, Would set the path to the same directory with an additional .alpackages.

Example:

  |-- .alpackages/     <-- the downloaded Symbols folder
  |-- apps/
     |-- app1
     |-- app2
  |-- .code-workspace
  |-- README.md

"settings": {
    "al.packageCachePath": "<Path to project directory>/.alpackages",
}

If you need to open a single app and need to compile it you can simply download the symbols or change the settings.json to make use of the centralized directory.

What do you think? @waldo1001 could this be created as a Best Practice?
I do like to get a second opinion by @JesperSchulz. When we think about the BusinessCentralApps repo, as far as I can tell, the dependencies are stored in the individual project folder. Is this the recommended way to develop in a workspace? To leave all the redundant dependency-app-files in the single project folders?

I'm currently making use of the "Publish full dependency tree for active Project" VS Code command, but haven't found anything to download the symbols for every single app, as this would be required to make every app compilable w/o a centralized directory for the symbols. With a centralized directory for the symbols there is only one single Microsoft_Application_x.x.xxxxx.xxxxx.app file for the entire project.

[fvet]

We tried using the above approach with one workspace containing all our apps, but this have serious impact on the VS Code performance (loading 30+ apps in one workspace is not quit fast).

For each app, we added a separate code-workspace file containing the app + it's dependent apps folders. (Multiplied by the number of apps)

All of these workspaces share the same .\alpackages