Business Central: AL Compiler

The Business Central AL Compiler

When you start looking into build automation, one of the first things you’ll need to figure out is how to build an AL project without Visual Studio Code. This blog post serves as a brief introduction to finding the AL compiler and how to run it from the command line.

Where to find the AL compiler

The Business Central AL compiler is shipped inside the AL Language extension (vsix) file. The easiest way I find to get the correct compiler version is to create a docker container using the Business Central image version required and extract the VSIX file. The container will provide a HTTP download link to the AL Language extension, but I prefer to copy the VSIX file to the local file system from the containers C:\Run directory using the docker cp command.

The VSIX file is essentially a zip archive, so with 7zip installed I can extract the contents of the AL Language vsix file as-is, but you can also change the file extension to zip so the built in Windows zip tool can recognise the file. Of course we’ll want to script all this for automation, so as an example the following PowerShell can be used:

Copy-Item C:\Temp\*.vsix -Destination C:\Temp\alc.zip

Expand-Archive C:\Temp\alc.zip -DesintationPath C:\Temp\alc -Force

$CompilerPath = 'C:\Temp\alc\extension\bin\alc.exe'

The Expand-Archive Cmdlet requires the zip extension, so I first copy the vsix file and give the new file the zip extension.

Once the archive has been extracted you can find the AL compiler (alc.exe) in the \extension\bin directory:

Run the AL compiler from the command line

If we run the alc.exe application with the /? parameter,  the parameters supported by the AL compiler are printed to the screen:

Microsoft (R) AL Compiler version 2.1.1.13845
Copyright (C) Microsoft Corporation. All rights reserved

AL Compiler Options

- PROJECT DIRECTORY -
/project: Specify the project directory.

- OUTPUT FILE -
/out: Specify the output package file name (default: the name is generated from the project manifest as __.app).

- ERRORS AND WARNINGS -
/warnaserror[+|-] Report all warnings as errors.
/nowarn: Turn off specific warning messages.
/errorlog: Specify a file to log all compiler and analyzer diagnostics.
/ruleset: Specify a ruleset file that alters severity of specific diagnostics.

- SETTINGS -
/packagecachepath: Specify the cache location for the symbols.
/target: Specify the compilation target.
/features: List of feature flags.

- MISCELLANEOUS -
/parallel[+|-] Concurrent build. (Short form /p[+|-])

The minimum required parameters are:

• /project – to specify the AL project workspace root.
• /packagecachepath – to specify the location of the symbol files and any dependent app files.

So for example we could run the following:

> alc.exe /project:C:\Temp\AL\TestProject /packagecachepath:C:\Temp\AL\TestProject\symbols

If successful the built app file will be placed in the workspace root folder. Error and warning messages will be displayed in the console output.

How-to get the symbol app files?

So far so good, but if you you want to introduce build automation you’ll need a way of getting the latest symbol files for the compiler to reference.

When using Visual Studio Code to build projects, you’ve probably noticed that the symbol files are downloaded from the Business Central service’s developer end-point. We can achieve the same result programmatically using the PowerShell Cmdlet Invoke-WebRequest.

The following script serves as an example (the credential code came from here):

$user = 'admin'
$password = 'admin'
$containerName = 'BCLATEST'
$versionText = '13.0.0.0'
$symbolPath = 'C:\Temp\AL\TestApp\symbols'

$pair = "$($user):$($password)"

$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))

$basicAuthValue = "Basic $encodedCreds"

$Headers = @{
Authorization = $basicAuthValue
}

$SystemSymURL = 'http://{0}:7049/NAV/dev/packages?publisher=Microsoft&appName=System&versionText={1}' -f $containerName, $versionText
$AppSymURL = 'http://{0}:7049/NAV/dev/packages?publisher=Microsoft&appName=Application&versionText={1}' -f $containerName, $versionText

Invoke-WebRequest $SystemSymURL -OutFile "$symbolPath\system.app" -Headers $Headers

Invoke-WebRequest $AppSymURL -OutFile "$symbolPath\application.app" -Headers $Headers

As an aside, the version I’ve used above for the versionText parameter (13.0.0.0) is now outdated as the Business Central April release is versioned 14, however, using version 13.0.0.0 still currently appears to download the correct symbols even on the April ’19 release.

Thanks for reading,

Dan