[Question] Parameters used by VSCode to call alc.exe

[fvet]

Describe the bug We've a project with 4500+ objects, that is compiled quite fast via VS Code on our buildserver, with all codeAnalyzers enabled. Even with the appSourceCop.json containing a the "version" parameter, referencing a previous app file (approx. 30 Mb size) in .alpackages, all compiles with 1 - 1'30 minutes.

Making use of ALOps for our CI/CD, for the compile step, they issue a similar statement to the alc.exe to achieve the same: compiling a /project with the /al_analyzers, referencing a /package cache path, .... However, this takes either 10+ minutes or just simply fails if the 'AppSourceCop' analyzer is enabled (almost everytime an error is show that the app with version X referenced by AppSourceCop.json could not be found in the .alpackages folder, altough it is located in that location).

Possibly because we're referring to the previous app file by including it in the /alpackagecache folder.... Although it's a guess. Apparently, there might be some 'hidden' parameters on the alc.exe to reference the previous app file. Or we might not make full use of the parallel or maxdegreeofparallelism parameters.

Expected behavior Our questions are, to ease the troubleshooting when working directly via alc.exe:

• Is there an (easy) way to verify the parameters that are passed by VSCode to alc.exe upon packaging?
• Is there a log file where we can trace the actual alc.exe statement that is raised by VSCode for AL: Package?

[atoader]

VSCode does not call alc.exe when packaging. It completes the background compilation and generates a package. Which version of the alc.exe are you using in your pipeline? Is it the one from the VSIX?

[fvet]

I've used vsix version 5.3 (BC 16.3), 6.1 (BC 17) and 7.0 (insider), all resulting in the same issues. I might have been wrong in linking 'Package' with alc.exe (in my case in VS Code, the background compilation was disabled).

Waldo is facing the same and trying to find out what's wrong in the meanwhile. Nevertheless, it would be interesting if we could see which parameters the 'background compiler' receives.

[atoader]

We've identified an issue in AppSourceCop and we will be releasing an update later this month where the performance will be improved significantly. If you could show me what switches you are using for alc, I could tell you if anything stands out, but I don't think the difference in perceived performance comes from there. The background compilation caches a lot of artifacts and when you press "build" it only completes the compilation and creates the output package.

[fvet]

Some background (#https://github.com/HodorNV/ALOps/issues/248)

Alc switches used, with packagecachepath containing the previous app version and AppSourceCop refering to it with the 'version' parameter.

C:\bcartifacts.cache\onprem\16.3.14085.14238\VSIX\extension\bin\

& alc.exe /packagecachepath:"C:\Temp\x\App\.alpackages" /project:"C:\Temp\x\App" /out:"C:\Temp\a\xNavitrans_Core_16.3.0.5439_OnPrem_16.3_w1.app" /fullpaths /analyzer:"C:\bcartifacts.cache\onprem\16.3.14085.14238\VSIX\extension\bin\Analyzers\Microsoft.Dynamics.Nav.CodeCop.dll","C:\bcartifacts.cache\onprem\16.3.14085.14238\VSIX\extension\bin\Analyzers\Microsoft.Dynamics.Nav.UICop.dll","C:\bcartifacts.cache\onprem\16.3.14085.14238\VSIX\extension\bin\Analyzers\Microsoft.Dynamics.Nav.AppSourceCop.dll" /ruleset:"C:\Temp\x\App\.vscode\nvt.ruleset.json" /errorlog:"C:\Temp\x\App\error.log"

cd "C:\Users\fvet\.vscode\extensions\ms-dynamics-smb.al-6.1.359074\bin"

& alc.exe /packagecachepath:"C:\Temp\x\App\.alpackages" /project:"C:\Temp\x\App" /out:"C:\Temp\x\xNavitrans_Core_16.3.0.5439_OnPrem_16.3_w1.app" /fullpaths /analyzer:"C:\Users\fvet\.vscode\extensions\ms-dynamics-smb.al-6.1.359074\bin\Analyzers\Microsoft.Dynamics.Nav.CodeCop.dll","C:\Users\fvet\.vscode\extensions\ms-dynamics-smb.al-6.1.359074\bin\Analyzers\Microsoft.Dynamics.Nav.UICop.dll","C:\Users\fvet\.vscode\extensions\ms-dynamics-smb.al-6.1.359074\bin\Analyzers\Microsoft.Dynamics.Nav.AppSourceCop.dll" /ruleset:"C:\Temp\x\App\.vscode\nvt.ruleset.json" /errorlog:"C:\Temp\x\App\error.log"

[atoader]

There is nothing wrong with the switches. I think the root cause was a lack of caching in AppSourceCop. The fix should be released within 2 weeks to the insider preview.

[fvet]

@atoader Any plans to backport this to marketplace soon?

When running the alc from the insider vsix, seems like something has been fixed, at least it works for one of our smaller projects.

[fvet]

First tests using vsix 7.0.5.44790 on our larger Base app seem promising too. Got the compiler time down to +- 3 minutes.