al_build / al_compile do not pass al.assemblyProbingPaths — OnPrem projects using dotnet cannot be built through the AL MCP Server

[ricardoquintas4all]

Summary

When an AL project targets OnPrem and declares .NET assemblies, al_build and al_compile fail because the compiler receives an empty assembly probing path list, even though al.assemblyProbingPaths is configured and the assemblies are present on disk.

Invoking alc.exe directly with /assemblyprobingpaths compiles the same project cleanly, which suggests the value simply isn't being forwarded when the build is invoked through the agent tools.

Environment

• AL Language extension: 17.0.2273547
• AL Compiler: 17.0.34.45391
• Agent tooling: AL MCP Server (al_build, al_compile, al_getdiagnostics, al_getpackagedependencies, al_auth_login)
• OS: Windows 11
• app.json: "target": "OnPrem", "runtime": "16.0", "platform": "27.0.41766.0", "application": "27.1.41698.41776"
• The project declares several assemblies in a dotnet block (for example Microsoft.Data.SqlClient and WinSCPnet). All of them are present under .netpackages.

Steps to reproduce

1. Create/open an AL project with "target": "OnPrem" and a dotnet block declaring an assembly available in .netpackages.
2. Configure al.assemblyProbingPaths (workspace folder settings, .code-workspace, or user settings — we have it in all three).
3. Invoke al_build (or al_compile) through the AL MCP Server.

Expected

The build resolves the declared assemblies, as it does when building from Visual Studio Code.

Actual

AL0451: An assembly named 'Microsoft.Data.SqlClient, PublicKeyToken=null'
        could not be found in the assembly probing paths ''

Note the empty '' at the end. The same error is reported for each declared assembly, and cascades into follow-up errors wherever those types are used:

AL0185: DotNet 'SqlCommand' is missing
AL0185: DotNet 'Session' is missing
AL0185: DotNet 'ZipArchive' is missing

Every error reported for the project traces back to the unresolved assemblies.

Evidence that the configuration and the assemblies are fine

Invoking the same compiler binary manually, with the probing paths passed explicitly:

alc.exe /project:<project>
        /packagecachepath:<project>\.alpackages
        /assemblyprobingpaths:"<project>\.netpackages","C:\Windows\assembly","C:\Windows\Microsoft.NET\assembly\GAC_MSIL"
        /out:<out.app>

completes with zero errors and produces a valid .app. Same compiler, same source, same symbol packages — the only difference is the /assemblyprobingpaths argument.

Building the same project from Visual Studio Code also works normally.

What we tried

• al_build with and without projectPath
• al_build with scope: "current" and scope: "all"
• al_compile
• Reloading the VS Code window after editing the setting

All produce the same empty probing path list.

Impact

Any OnPrem project that uses dotnet cannot be built or validated through the agent tools. This is still common in Business Central solutions — SFTP clients, PDF utilities, SQL access. Cloud-target projects without dotnet build correctly, so the issue appears specific to this scenario.

Possible resolutions

Either of these would address it:

1. Forward the resolved al.assemblyProbingPaths value to the compiler when al_build / al_compile are invoked.
2. Expose assemblyProbingPaths as an optional parameter on al_build and al_compile, so an agent can supply it explicitly when the setting isn't discoverable — this would also help in headless/CI scenarios, where there is no VS Code workspace to read the setting from.