Inconsistent behavior when baselinePackageCachePath is used in AppSourceCop.json

[itsme112358]

Please include the following with each issue:

1. Describe the bug In our pipelines we use alc.exe directly to compile our source code because it is way faster than compiling inside a container. We use a directory outside of the project directory to download all the dependencies from our package management. When using baselinePackageCachePath property in AppSourceCop.json and the compiler behaves weird. It

2. To Reproduce In order for our developers to not have to download the legacy symbols for the local compiler to compare them and ensure there are no breaking changes, the "compare" version is contained in the repo in .\release. The AL project is located in .\app. In order to have the symbols available the baselinePackageCachePath is defined as .\\... That way the compiler searches all directories inside the repo, including the "regular" package path .\app\.alpackages and the "compare" version .\release. This works fine.

{
    "name": "xxx",
    "publisher": "yyy",
    "version": "1.2.3.4",
    "baselinePackageCachePath": ".\\..",
    "mandatoryPrefix": "pre",
    "supportedCountries": ["de","at"]
}

In our pipelines we copy all required packages from our package management to ensure we always use the currently released versions of dependencies. The compare symbols are also copied from

# pipeline workspace
C:\...\5

# repo
C:\...\5\repo

# AL project
C:\...\5\repo\app

# AL packages directory --> Download all required symbols here
C:\...\5\packages

# Compare version for breaking changes
# This is in the repo so all developers have the "legacy" symbols right away
C:\...\5\repo\release\xxx.app
Copy-Item C:\...\5\repo\release\xxx.app C:\...\5\packages

So basically all symbols that would be required are now located in C:\...\5\packages Then alc.exe is called like this

Invoke-Command -ScriptBlock ([scriptblock]::Create("alc.exe /project:'C:\temp\appsourcecoptest\5\s\app' /analyzer:'C:\buildtools\compiler\Analyzers\Microsoft.Dynamics.Nav.CodeCop.dll,C:\buildtools\compiler\Analyzers\Microsoft.Dynamics.Nav.AppSourceCop.dll' /packagecachepath:'C:\temp\appsourcecoptest\5\packages' /assemblyprobingpaths:'c:\bcartifacts.cache\onprem\23.11.23421.0\platform\ServiceTier','c:\bcartifacts.cache\onprem\23.11.23421.0\platform\Prerequisite Components','C:\Windows\Microsoft.NET\assembly' /parallel+ /buildby:'EX62-02'"))

As long as we don't use baselinePackageCachePath property in AppSourceCop.json everything works as expected.

3. Expected behavior alc.exe uses explicit packagecachepath parameter to determine packages (including baseline packages). 4. Actual behavior "precompile" works fine, then the comparison for breaking changes with previous version fails. alc.exe throws tens of thousands of errors because it uses some undedined symbols for the breaking changes comparison. It does not complain about not finding the "old symbols" as it would if it couldn't find anything.

5. Versions:

• alc.exe: 13.1.16.16524
• Visual Studio Code: Version: 1.93.1 (system setup) Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40 Date: 2024-09-11T17:20:05.685Z Electron: 30.4.0 ElectronBuildId: 10073054 Chromium: 124.0.6367.243 Node.js: 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.17763
• Business Central: 23.11.23421.0
• List of Visual Studio Code extensions that you have installed: AL language v13.1.1065068 (Irrelevant)

6. Workaround: I now copy the packages into the same directory where the "compare app" lies: C:\...\5\repo\release\ and use this as the packagecachepath. This adds some overhead though, since we check our repo for changes after the compile in order to prevent anyone pushing changes without recompiling locally and forgetting to add all their modified files. (translations file and report layouts are changed on compile). Therefore we have to manually delete the packages again before running the check. This is a) annoying and b) prohibits us from reusing packages if they're already downloaded and up to date.

7. Proposed Solutions

1. When packagecachepath parameter is used, use this directory to search for all packages including baseline packages and ignore baselinePackageCachePath property in AppSourceCop.json. (this would still be a bit intransparent)
2. When packagecachepath is used, use it for packages and additionally use packages found in baselinePackageCachePath property from AppSourceCop.json (as far as I can tell, this is how it works in vscode). This would be the most intuitive approach.
3. Provide additional parameter for baselinePackageCachePath in alc.exe. This would be the most transparent approach.