Dynamics 365 Business Central: automatic .NET runtime acquisition on AL Language Extension.

Less than 1 month ago I wrote this post: AL Language extension and macOS: what’s next? announcing changes in the AL Language extension .NET runtime discoverability. And here we are…

The latest release of the AL Language extension switches to automatic .NET runtime acquisition via the .NET Install Tool for VS Code. On startup, the extension checks whether the required .NET 10.0 runtime is present and, if not, downloads and installs it automatically. Should this acquisition step fail post-activation, AL Language will fall back to any compatible ASP.NET Core runtime already available through the system’s dotnet command.

This shift brings a major benefit: extension size drops considerably, since platform-specific runtime bundles for Windows, macOS, and Linux are no longer shipped alongside it. Main advantages I can see are the following:

• Smaller extension package: by dropping the practice of bundling separate runtime binaries for Windows, macOS, and Linux, the extension’s install size shrinks meaningfully (from almost 500MB down to less the 25MB). And this means faster downloads, less disk usage, quicker updates.
• Lower long-term maintenance burden for Microsoft: decoupling the extension from platform-specific runtime packaging makes it easier for them to ship runtime updates independently of extension releases.
• A more resilient activation flow: the fallback to an existing ASP.NET Core runtime means a failed download doesn’t necessarily block you from working (the extension degrades gracefully rather than failing outright).

At the moment, users of BCContainerHelper tool (that remember it will be deprecated and unsupported soon) can see some issues after this change.

altool (the tool BcContainerHelper uses to inspect .app files) now needs .NET 10 to run. But the automatic download logic in BcContainerHelper is broken because it tries to fetch .NET, grabs an old, wrong version (.NET 6.0 instead of 10), and then still can’t find a dotnet command to run. So the auto-fix fails, and the whole compile step crashes.

The simple fix: install .NET 10 yourself, manually, before running your build.

That sidesteps BcContainerHelper’s broken auto-download entirely (instead of relying on it to fetch the right runtime, in this way you make sure it’s already there).

• On Windows: just install the .NET 10 runtime (or SDK) normally.
• On Linux (e.g. CI agents, build containers): add a step in your pipeline/Dockerfile to install .NET 10 before the build runs, so dotnet is available in PATH when altool needs it.
• On macOS: same approach (install .NET 10 manually first).

altool only falls back to auto-downloading when it can’t find .NET already on the system. If you pre-install .NET 10 yourself, that broken download path never gets triggered (altool just uses the right .NET version).