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.

[thpeder]

Hi @itsme112358 ,

The BaselinePackageCachePath is to specify a folder where AppSourceCop will look for all the packages (.App files) that should go into the baseline of the breaking changes validation. This will include the older version of the current app and also all of the dependencies of the previous version. For example. MyApp Version 1, depends on Application 14.0 MyApp Version 2 (Current version), depends on Application 15.0

Here the baseline is Application 14.0 with all of its version 14 dependencies. It is not only for the application dependency but for all dependencies involved, including also if you have some library apps of yours. This is the approach the appsource submission validation is using to get the most accurate view.

If you don't specify BaselinePackageCachePath and set it up like this, then it will for all the depednencies load the highest version available, instead of the indented one.

I think the issue you are hitting is that the BaselinePackageCachePath cannot look outside of the current project, meaning ./.. is not possible. If you want this, please go and create an idea on aka.ms/bcideas

[thpeder]

A workaround to not copy all the files into one folder. is you can instead specify multiple folders for the PackageCachePaths.