microsoft/AL is the issue tracker and sample shelf for the AL language

What the repository is actually for

The description in the repository metadata gives the purpose away in one clause. It is the home of the Dynamics 365 Business Central AL Language extension for Visual Studio Code, and it is used to track issues regarding the latest version of the AL compiler and the developer tools available in the Visual Studio Code Marketplace or as part of the AL Developer Preview builds.

So this is a support and reference repository, not the extension's source. The extension itself is published on the Visual Studio Code Marketplace, and the repository is where problems with it get filed. The README says so in the same breath as what else you will find here, code samples to help you get started writing extensions in AL and get familiar with the tools.

That combination, a compiler issue tracker next to a set of runnable examples, is a common and sensible shape for a vendor's language tooling. The issues tell the vendor what is broken in the current compiler. The samples show what working code looks like. Neither is a build you can point a CI job at.

The default branch is master, the repository is not archived, and the last push was on 2026-10-19, so the samples and the issue tracking are both current. There are no GitHub releases, because there is nothing here to release.

The primary language listed for the repository is PowerShell, which reflects the tooling scripts in the tree rather than the AL code in the samples, and the topic list is all Business Central and AL Language, with the bcopensource tag on it.

Nine sample projects, and the ones worth reading first

The samples directory is the substantive part of the repository, and the names describe what they demonstrate better than any documentation would.

There is a HelloWorld sample, which is where a new AL developer should start. There is a TowersOfHanoi sample, which is a puzzle rather than a business scenario, and is the sort of thing that exists to show a control add-in or a page with behaviour. There are two control add-in samples, ControlAddIn and ControlAddInHighCharts, the second of which pairs the add-in with a charting library, and a DotNetReplace sample that shows the .NET interop path.

Then there are the ones that touch the platform. A GetAddressService sample suggests a service that resolves an address, and an UploadViewPictures sample covers uploading and viewing images, which is a recurring requirement for Business Central pages. A PageBackgroundTask.Currency sample is about a background task running on a page, in this case around currency.

The mix is the point. A developer learning a business application language needs to see the platform idioms, and these cover the three that matter most: how a page is built, how you call out to .NET, and how a long-running job is attached to a page. That is a better curriculum than any single tutorial because each sample isolates one mechanism.

The repository also carries a grammar directory, a highlightjs_al directory and a snippets directory. Those are editor support artefacts, a TextMate grammar, highlight.js support and ready-made snippets, which tells you the repository is also where the tooling that makes writing AL feel like writing in a language with tooling is developed.

Where the actual documentation lives

The README's documentation section sends you to the Microsoft Dynamics 365 Business Central docs, and it names three pages: Getting Started, Building Your First Sample Extension, and the Developer Reference.

The choice to delegate documentation to the docs site rather than write it in the repository is consistent with the rest of the the arrangement. The AL Language extension, the compiler and the AL Developer Preview builds all move on Microsoft's schedule, and a document that lived in the repository would be one more thing to keep in step. The docs site is versioned alongside the product, and a link does not rot the way a copied page does.

The same pattern appears in the support section, which points at three community resources rather than hosting a forum: the Business Central Community on community.dynamics.com, Yammer groups for partners, and the mibuso forum. For issue routing, diagnostics and performance guidance, there is a separate SUPPORT.md in the repository, so the distinction between a compiler bug and a configuration question has a written answer before anyone opens a ticket.

There is also a triage process document, linked from the bug reporting section, describing how incoming requests are handled. That matters more than it sounds. A language toolchain receives a mixed stream of genuine compiler defects, feature requests and misconfiguration, and a published triage process is how a project keeps that stream actionable.

The result is that a reader of this repository is being routed rather than served, which is the right shape for a vendor-owned language.

News.md is where the compiler changes are recorded

The repository root carries a News.md file alongside the README, the contributing guidelines, the issue template, a security policy and a support document, and it is the one artefact here that is updated as the compiler changes.

That matters because the issue tracker follows the compiler, and a repository that only collected bugs would tell you what is broken but not what changed. A file recording what moved in the language, and in the developer tools, gives a developer the context needed to decide whether an issue they are about to file is a new defect or a known change they have not read about yet.

The other root files are the usual support scaffolding with one addition worth noting. Alongside the CONTRIBUTING.md, CODE_OF_CONDUCT and SECURITY documents, there is a dedicated SUPPORT.md for issue routing, diagnostics and performance guidance, which sits alongside a wiki page describing the triage process. A compiler toolchain generates a lot of reports that are configuration mistakes, and separating that from real defects before a developer spends an afternoon on a ticket is a service to both sides.

There is also a resources directory and a scripts directory in the tree, along with an ISSUE_TEMPLATE directory that shapes what a good report looks like before it is filed. For a project that exists partly to funnel problems to the right team, that filing template is one of the more useful files in it.

Preview builds, and what a contributor is actually signing up for

The AL Developer Preview builds are the one part of the setup with a gate. The README is explicit that to get access to them you need to be part of the Ready2Go program, with the detailed instructions on the Business Central developer documentation site.

That is a meaningful constraint for anyone evaluating this toolchain, because the preview builds are where the newest compiler behaviour appears first. If you are working on something that depends on a language feature that has not shipped, the preview is the only way to see it, and the preview is gated.

The contributor side has its own condition, and the README states it twice: for bugs and feature requests, read the contributing guidelines first and then search existing and closed issues. Bugs pertaining to the AL compiler and the developer tools for the latest version can be filed in this repository, and the response is on a best-effort basis.

Best effort is the phrase to hold on to. A free issue tracker for a commercial product's compiler means the feedback loop is slower than a commercial support contract, and the triage process document is where the expectations are set.

On the legal side the repository is straightforward. It is licensed under the MIT licence, with the file named LICENSE.TXT at the root, and the copyright line reads Copyright (c) Microsoft Corporation, all rights reserved. The project has adopted the Microsoft Open Source Code of Conduct, with a link to the FAQ and a contact address for questions. There is a SECURITY.md as well.

One more thing a reader should know. The README points to related repositories that will often be the actual answer to a problem: ALAppExtensions for the application foundation modules and add-ons, the MicrosoftDocs repository for the Dynamics 365 Small and Medium Business developer documentation, and the official BcContainerHelper repository, a PowerShell module that makes working with Business Central containers on Docker easier. That last one is the tool a developer reaches for when the problem is a local environment rather than the language.

Editorial conclusion

microsoft/AL suits a Business Central developer who wants working AL examples to read and a place to report compiler and tooling problems, and who is starting from the standard AL tooling rather than from a fork. It is the wrong thing to depend on as a library, because the repository holds samples and an issue tracker rather than a package, and it is the wrong place to look for the extension itself, which is distributed through the Visual Studio Code Marketplace. Before you rely on it, read the samples directory rather than the README, because the README is a pointer to documentation and to community forums, and check News.md for what changed in the compiler, since that is what the issue tracker actually follows.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/AL on GitHub
4. README