Using baselinePackageCachePath in combination with packageCachePath does not find the MS System App.

[fvet]

Please include the following with each issue:

1. Describe the bug
The baselinePackageCachePath fails to work together with the packageCachePath.

2. To Reproduce
Steps to reproduce the behavior:

I my personal settings.json, I've referenced a custom path for my packageCachePath.
This eliminates the need to store hundreds of MS Apps (Application, base application, system, ...) per repo / per folder / per app. Especially when working on a suite of apps this is extremely usefull to maintain only one version of an app file.

"al.packageCachePath": "C:\\Projects\\Dynavision\\.alpackages",

In the appsourcecop.json I want the AppSourceCop to verify against my 19.0.0.0 app.

{
    "supportedCountries": ["BE"],
    "mandatoryAffixes": ["ESCA"],    
    "version": "19.0.0.0"
}

This works perfectly!

The MS base application, system app, ... seems to be taken from C:\Projects\Dynavision.alpackages
The dependend 19.0.0.0 app is taken from the projects .alpackages path (stored under C:\Projects\Dynavision*Dynavision Core\App*.alpackages)

And the appsourcecop warning is shown.

---

However, when I make use of the new baselinePackageCachePath settings to change the folder for the previous apps to /.appSourceCopPackages ....

{
    "supportedCountries": ["BE"],
    "mandatoryAffixes": ["ESCA"],    
    "version": "19.0.0.0",
    "baselinePackageCachePath": "./.appSourceCopPackages"
}

... I get below error.

Apparently the compiler is no longer looking for the MS base application, system app, ... in my personal central folder C:\Projects\Dynavision.alpackages. I don't want to maintain another copy of the apps under the App/.alPackages, neither under the App/.appSourceCopPackages path again. Neither can I set the "al.packageCachePath" in the folders settings.json, since C:\Projects\Dynavision.alpackages is too hardcoded.

The reason why we would like to switch to the baselinePackageCachePath is we can put the previous versions separated from any other dependent apps. This would also be easier to include/exclude .app files from our source control / git.

Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (i.e. .gif) is not sufficient.

3. Expected behavior
Allow the use of baselinePackageCachePath combined with the packageCachePath from the personal settings.json.

4. Actual behavior
A clear and concise description of what happened accompanied by images, animations, or a link to a video showing the issue occurring

5. Versions:

• AL Language:
  Name: AL Language
  Id: ms-dynamics-smb.al
  Description: AL development tools for Dynamics 365 Business Central
  Version: 9.0.578744
  Publisher: Microsoft
  VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-dynamics-smb.al

• Visual Studio Code:

• Business Central:

• List of Visual Studio Code extensions that you have installed:

Final Checklist

Please remember to do the following:

• Search the issue repository to ensure you are reporting a new issue

• Reproduce the issue after disabling all extensions except the AL Language extension

• Simplify your code around the issue to better isolate the problem

[qutreson]

@fvet what you are describing here is by-design. The setting is documented as follows: The path to the folder containing the baseline and its dependencies with which you want to compare the current package for breaking changes. By default, the package cache path for the current project is used (see 'al.packageCachePath' setting) , see https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/analyzers/appsourcecop#configuration.

It is expected that you will have the baseline extension along with all its dependencies in the folder that you use as baselinePackageCachePath. This setting was introduced in order to allow having different versions of the dependencies for the baseline and the current extension (for example, the baseline could depend on Base Application version 18.0, while the current extension depends on Base Application version 19.0). If the current extension and the baseline were sharing the same folder for their dependencies then only the latest version would be loaded (version 19.0 would be the only one loaded).