https://stefanmaron.com/tags/open-source/Recent content in Open Source on Stefan Maron | Business Central & AL DevelopmentHugo -- gohugo.ioThu, 10 Sep 2026 07:33:46 +0200https://stefanmaron.com/posts/bcdb-restore-write-a-cloud-export-into-a-container/Thu, 10 Sep 2026 07:33:46 +0200https://stefanmaron.com/posts/bcdb-restore-write-a-cloud-export-into-a-container/bcdb could already open a .bak or a .bacpac and read anything in it, no SQL Server involved. That was genuinely useful for AL Runner , which is why I built it in the first place, but it didn’t do much for a developer’s normal day. For that, you want the data sitting in a database you can query, click through, and run BC against. Since v0.2.0, bcdb restore is what changes that: it writes a source’s rows straight into a container that’s already running, and it doesn’t ask the container’s schema to match the source first.https://stefanmaron.com/posts/al-runner-autonomous-agent-weekend/Tue, 08 Sep 2026 07:33:56 +0200https://stefanmaron.com/posts/al-runner-autonomous-agent-weekend/I last wrote about AL Runner on September 3, covering the test suite that verifies its behavior against real BC . Since then I got funded for an additional Claude Max 20x subscription, dedicated specifically to AL Runner work. Combined with the Max 20x subscription I already had, that gave me a Max 40x usage window, and a token usage reset on Friday, September 5 made the whole thing available fresh going into the weekend.https://stefanmaron.com/posts/al-language-tests-executable-spec/Thu, 03 Sep 2026 06:00:00 +0200https://stefanmaron.com/posts/al-language-tests-executable-spec/I’ve written a lot about AL Runner on this blog — most recently the Cronus data and mutation-testing update two days ago. What I haven’t written about is the repository that makes AL Runner trustworthy in the first place: BusinessCentral.AL.Language.Tests . The problem it solves AL Runner is an emulator. It reimplements the AL language and a chunk of the BC platform in-memory so your tests run in seconds instead of the minute-plus it takes to spin up a real service tier.https://stefanmaron.com/posts/al-runner-tests-against-cronus/Tue, 01 Sep 2026 18:30:00 +0200https://stefanmaron.com/posts/al-runner-tests-against-cronus/I last wrote about AL Runner on August 20, covering v2.2 and v2.3. Seven releases have shipped since then, through today’s v2.10.0, and the headline one connects directly to the post I wrote this morning about bcdb : you can now point AL Runner at a real BC backup and test against the actual data in it, starting with the Cronus demo database every BC sandbox artifact ships with. Testing against real Cronus data Up to now, AL Runner’s in-memory database started empty and stayed empty except for whatever your own test code inserted.https://stefanmaron.com/posts/bcdb-read-business-central-backups-without-sql-server/Tue, 01 Sep 2026 09:40:40 +0200https://stefanmaron.com/posts/bcdb-read-business-central-backups-without-sql-server/Say someone hands you a customer’s BC backup and you need to check one field on one table. The normal path is: find or spin up a SQL Server, restore the file, wait for however long that takes on however large the database is, connect, query, and then decide whether to keep that SQL Server around or tear it down. All of that just to read a handful of values.https://stefanmaron.com/posts/weekly-recap-2026-08-28/Fri, 28 Aug 2026 09:30:00 +0200https://stefanmaron.com/posts/weekly-recap-2026-08-28/The feature side of AL Runner’s week — real Cronus data via --test-data, breakpoint debugging back via --dap, per-test coverage for mutation testing — is already its own post . This recap covers everything else that shipped in the same window: a CI incident and its fix in AL Runner, two real-world bugs in the Linux fast lane, a first update in two years for a browser extension, and a contribution to a project I don’t maintain.https://stefanmaron.com/posts/weekly-recap-2026-08-21/Fri, 21 Aug 2026 09:30:00 +0200https://stefanmaron.com/posts/weekly-recap-2026-08-21/Two posts went out on their own this week: I Can Turn Off My Code. I Can’t Turn Off Yours. on the 18th, making the case that whether a trigger needs to run shouldn’t be a compile-time guess when the platform can answer that question itself at runtime, and AL Runner v2.2 and v2.3 on the 20th, covering coverage reporting, inline execute, and a watch mode that stopped lying to you mid-save.https://stefanmaron.com/posts/al-runner-coverage-execute-and-a-guard-that-worked/Thu, 20 Aug 2026 07:00:00 +0200https://stefanmaron.com/posts/al-runner-coverage-execute-and-a-guard-that-worked/I last wrote about AL Runner on August 10, the day the v2 rewrite shipped — the tool that runs your AL unit and integration tests without spinning up a BC service tier. The weekly recap four days later covered the first round of follow-up fixes. This post covers what happened after that, through v2.3.1 on August 19: two new capabilities, a watch mode you can actually trust during a busy editing session, and roughly 130 fixes to places where the runner used to disagree with real Business Central.https://stefanmaron.com/posts/al-runner-v2-emit-through-bc/Mon, 10 Aug 2026 07:00:00 +0200https://stefanmaron.com/posts/al-runner-v2-emit-through-bc/Last time I wrote about AL Runner , it ran your AL unit tests without a service tier by transpiling AL to C#, renaming BC’s runtime types (NavRecord became MockRecord, and so on), and stubbing out anything it didn’t recognize. It worked. 3,400 tests passed. Then the feedback started coming in from companies actually trying to use it, and it was consistent: the runner does what it says it does, for the use cases described.https://stefanmaron.com/posts/bc-code-atlas-grounded-search-for-agents/Mon, 10 Aug 2026 07:00:00 +0200https://stefanmaron.com/posts/bc-code-atlas-grounded-search-for-agents/Ask an AI coding agent where BC validates a sales order before posting, and it will confidently give you a procedure name. Sometimes that name is real. Sometimes it’s a plausible-sounding hallucination assembled from training data that’s a few versions stale. Either way, the agent isn’t looking anything up — it’s pattern-matching against what it remembers, and it has no way to tell you which one it’s doing. I’ve been building bc-code-atlas to fix that, and I’m announcing it publicly today.https://stefanmaron.com/posts/al-runner-run-al-tests-without-bc/Fri, 24 Apr 2026 07:00:00 +0200https://stefanmaron.com/posts/al-runner-run-al-tests-without-bc/One Sunday afternoon in March I was playing with my daughter when a thought struck me out of nowhere: what if we could run AL code directly? Not through the service tier, not through a container — just… run it. I fired up the PC, set Claude Code loose on the investigation, and went back to playing. By the time we were done, there were some very interesting findings waiting for me.https://stefanmaron.com/posts/optimizing-bc-code-history-range-requests/Fri, 27 Feb 2026 07:00:00 +0100https://stefanmaron.com/posts/optimizing-bc-code-history-range-requests/The MSDyn365BC.Sandbox.Code.History repository automatically tracks every version of the Microsoft Business Central application source code across roughly 50 countries. Two GitHub Actions workflows run daily, picking up new BC sandbox artifacts and committing the AL source to version-controlled branches. It works well — but builds had started failing silently, and once I started digging in, things unraveled fast. Fixing what was broken first The original trigger was rebase failures. When late hotfix versions created merge conflicts during git pull --rebase, the scripts relied on fragile output string matching to detect and resolve them.