Business Central AL for VS Code Auto-Downloads .NET 10 and Uses VS Code Sign-In

The roadmap lists the item as Launched, at General Availability, for the Worldwide (Standard Multi-Tenant) cloud, with general availability in October 2026. Today is October 1, so that month has only just started. The record does not give a rollout day, so don't assume every developer already has it.

What Microsoft says is changing​

The roadmap description makes three claims:

• Automatic .NET runtime acquisition. The extension gets the required .NET runtime itself, so developers don't have to install it first.
• VS Code authentication by default. The extension uses Visual Studio Code's sign-in instead of its own separate prompts.
• A smaller extension. The AL extension no longer ships a separate runtime copy for each supported operating system.

Microsoft says the result is less time spent installing runtimes and dealing with sign-in prompts, and a more consistent setup on Windows, macOS and Linux. That covers local VS Code and browser-hosted environments.

The AL Language extension is the VS Code tool for Business Central's AL compiler and developer tools. It is how partners and in-house teams build Business Central extensions. A small change to this tool affects nearly every AL developer.

Summary: This changes the developer toolchain only. It does not change Business Central application features or how extensions are deployed.

How the runtime change works​

The roadmap entry is short, but Business Central MVP Stefano Demiliani wrote about the change on his blog on September 7. He wrote that 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.

He also describes a fallback: 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. In practice, a blocked download does not always mean a broken extension.

On package size, he reports that the install size drops from almost 500MB down to less the 25MB, or roughly 95% smaller. Microsoft's roadmap entry only says "smaller" and gives no number. Treat the figure as one experienced developer's reported number, not an official Microsoft benchmark.

Demiliani lists other benefits too. He says Microsoft can now ship runtime updates independently of extension releases. He also says that if the download fails, the extension degrades gracefully rather than failing outright.

Summary: The extension no longer ships a .NET runtime for every operating system. It uses the .NET Install Tool to get .NET 10.0 when needed, and can fall back to a compatible runtime already on the machine.

Authentication: less is documented​

The authentication change has much less public detail. Microsoft says only that the AL extension will use Visual Studio Code authentication by default. Neither the roadmap nor the community write-ups found for this article explain:

• which sign-in flow is used, or how it behaves with Conditional Access policies
• whether existing sign-in settings carry over automatically
• whether developers can opt out and keep their current method
• whether on-premises targets behave the same as Business Central online

"By default" suggests other methods still exist, but Microsoft hasn't said so directly. Teams with unusual identity setups should test before relying on it. A setting named "default" usually leaves room for exceptions.

Summary: Expect fewer separate sign-in prompts. Microsoft has not published enough detail to promise that every tenant setup will work smoothly.

Where it fits in the 2026 wave 2 cycle​

This item is one of several developer changes in Business Central's autumn release. Community blogger thinkaboutit.be listed the version 29.0 preview contents and included simplified AL setup in Visual Studio Code, automatically acquiring the required .NET runtime and defaulting to Visual Studio Code authentication. The same list includes ALTool command line testing, which works with CI pipelines, and a standalone AL language server for running language intelligence features outside Visual Studio Code.

The roadmap entry has no release-wave label, and there is a reason. According to 365Vanguard, Microsoft retired the release wave model in September 2026 and folded Dynamics 365, Power Platform, and Dataverse capabilities into the continuously-updated AI at Work roadmap. The same site reports that version 29 entered public preview in early September, with general availability landing the first week of October. That fits the October date on item 573356.

The Mac and Linux part has history behind it. A community overview of Business Central's developer history lists a Linux AL extension among the changes in Business Central 2023 wave 2. Demiliani's September post also follows an earlier one on what's next for the AL Language extension and macOS. With one shared runtime approach instead of three bundles, Mac and Linux setup should get closer to the Windows experience.

Don't overread the cross-platform claim​

Microsoft's documentation still sets the formal support boundaries. The system requirements page for Business Central 2026 release wave 1 (version 28) lists these for AL development:

• Operating systems: Windows 11 Enterprise, Education and Pro (supported versions), Windows Server 2025 and Windows Server 2022
• Software: Visual Studio Code and the AL Language extension
• Hardware: 500 MB of disk space, four CPU cores, and 16 GB of RAM (32–64 GB for local deployment of extensions with more than 1,000 objects)

The roadmap item promises a more consistent setup across Windows, macOS and Linux. It does not publish a new support matrix, and it does not change the documented requirements. Check the version 29 requirements page before treating a MacBook as a supported AL workstation for your team. The 500 MB disk figure may need updating if a much smaller extension becomes standard, but nothing published yet says it has changed.

What to do now​

For individual developers, the change should make setup easier. Corporate machines are where problems are most likely:

1. Check outbound access. The extension now downloads its runtime instead of carrying it, so locked-down machines and build agents need to reach Microsoft's .NET download endpoints. Proxies, TLS inspection and firewall rules are the likely blockers.
2. Plan a fallback. If downloads are blocked, Demiliani's report suggests a compatible ASP.NET Core runtime already installed through the system dotnet command can serve as the backup. Teams in tightly controlled environments may want to install it in their base image ahead of time.
3. Look at your images and containers. Dev containers, pre-built VMs and browser-hosted workspaces built around the old bundled-runtime extension should be rebuilt and tested, not assumed to work.
4. Test sign-in against your real tenant. Try the new default with a normal account and a Conditional Access-restricted account before rolling it out to the whole team.
5. Expect gradual availability. Microsoft's roadmap states that release dates are estimates and that entries may be removed once a feature is generally available, cancelled or postponed.

The verdict​

Few people will celebrate a smaller VS Code extension. Still, cutting a download of nearly 500 MB to a few dozen megabytes and removing a setup step gives developers back a bit of time on every machine they configure. The runtime change is well documented through Demiliani's hands-on report. The authentication change is promising but thinly specified, so verify it in your own environment before relying on it.

If your team has a "how to set up AL" wiki page, plan to update it. It should get shorter. Expect a new step about checking that machines can reach the .NET download endpoints.