2026
Since v0.2.0, bcdb can load a Business Central export into a running container in seconds, without needing the schema to match first. Getting the defaults safe took locking myself out of my own admin login.
394 commits and 351 merged pull requests since September 3, from implementation and review agents running against AL Runner continuously since Saturday. What came out of it: a Windows cross-check that caught a real BC-on-Linux gap, a first honest measurement of test coverage against Microsoft's own test suite, and one hang bug traced to a report running 101,000 extra times.
Why I built a separate test suite that runs against a real BC service tier instead of AL Runner's in-memory emulator: 101 merged PRs and 566 AL files identifying exact AL language behavior, so AL Runner has a known-correct answer to match and I find out fast if Microsoft ever changes that behavior.
v2.4.0 through v2.10.0: you can now hydrate the runner's in-memory database from a real BC backup and test against actual Cronus data, breakpoint debugging is back, coverage can now be attributed per test for mutation testing, and one change that fails runs the old runner used to let through.
A command-line tool and .NET library that decode a BC .bak or .bacpac file directly — no SQL Server, no restore, no service tier — verified page-for-page against a real restore.
AL Runner's CI tooling got a week of hardening after a squash-merge bug ate a required check, the Linux fast lane fixed two bugs that only showed up on real pipelines, OpenPageInspection got its first update in two years, and I shipped Azure CLI auth to navapi, someone else's project.
AL Runner's dedicated post already covered v2.2/v2.3, but releases now gate on tests too; pushing the Linux fast lane onto a second repo surfaced a Windows PowerShell 5.1 JSON bug that had silently broken CI on two repos since day one; a graphify-al fork that had drifted 677 commits behind upstream got resynced, catching a live dependency landmine along the way; and a few smaller fixes landed in a WordPress migration script and in vsc-lintercop's LinterCop-to-ALCops migration notice.
Since the v2 cutover: code coverage for your AL test runs, running a snippet of AL without writing a codeunit for it, a watch mode that no longer reports fake failures mid-save, and about 130 fixes to places where the runner's behavior didn't match real BC. Plus shoutouts to the two AL developers whose bug reports drove most of them.
An MCP server that gives an AI coding agent — or you — grounded access to the actual Business Central Base Application source, across versions and countries, with every result verified against the real file.
v1 worked for the use cases it was built for. Companies actually using it told me that wasn't enough — most real extensions can't be unit tested at all without running against real Microsoft or ISV code. That feedback drove a clean v2 cut. It also changed how the runner fails: anything it can't support now throws loudly instead of quietly passing.
A standalone CLI tool that transpiles your AL source to C#, rewrites BC runtime types to in-memory mocks, and executes your test codeunits in seconds — no container, no SQL Server, no license required.
Fixing silent failures in the BC Code History pipeline, then cutting daily runs from 4–5 hours to under 90 minutes with partial ZIP downloads via HTTP Range requests.