Step 1 — Add Base BC Code¶
Before your agent can make good design decisions, it needs to see how Business Central actually works. Not guess. Not hallucinate. Read the source code.
When you ask an agent "how should we implement cars for rental in BC?", the quality of the answer depends on whether the agent can actually look at how BC handles assets, items, and service objects under the hood. There are two ways to give it that access.
Give the agent the actual AL source of the entire Business Central codebase — Base Application, System Application, and all modules. Implementation, events, triggers, the whole working code.
Microsoft has promised to publish the full BC source on GitHub in June 2026. Until then, the community has solved this for us. Stefan Maron maintains MSDyn365BC.Sandbox.Code.History — every localisation of every BC version, kept up to date.
We'll mount the US localisation of BC 28 into your workspace as a git submodule.
There are symbol-based MCPs — Stefan Maron's AL Dependency MCP and Microsoft's AL MCP — that point the agent at the .alpackages/ symbol files. Symbols give the agent object names, field lists, procedure signatures, and return types. But they don't give source code. You can see what exists in BC, not how it works.
We'll wire these up later in the workshop. They're useful for fast lookup, compilation and testing, but for high-level architectural design they're not enough on their own.
What's a git submodule?¶
A submodule is a way to embed one git repository inside another, without copying its files into your repo's history.
- The base BC code lives in its own repo on GitHub. You don't fork it. You just point at it.
- Locally, the files appear in
external/MSDyn365BC/so your agent (and your IDE) can read them like any other folder. - In your repo, all that's tracked is a small pointer: "this folder is repo X at commit Y on branch Z". A few hundred bytes.
- Your remote stays small. Other people who clone your repo can pull the submodule on demand.
The base BC code is huge. A submodule lets you have it locally for your agent without bloating your project repo or git push-ing thousands of files you didn't write.
One-time setup
You only do this once. The submodule sticks with the repo from now on.
Add the submodule¶
Run these commands from the repo root.
1) Clone only the branch you need (shallow)
git clone -b us-28-vNext --single-branch --depth 1 https://github.com/StefanMaron/MSDyn365BC.Sandbox.Code.History external/MSDyn365BC
2) Register the folder as a submodule
git submodule add --force -b us-28-vNext https://github.com/StefanMaron/MSDyn365BC.Sandbox.Code.History external/MSDyn365BC
3) Persist the branch and shallow behaviour
git config -f .gitmodules submodule.external/MSDyn365BC.branch us-28-vNext
git config -f .gitmodules submodule.external/MSDyn365BC.shallow true
4) Commit
git add .gitmodules external/MSDyn365BC
git commit -m "Add MSDyn365BC submodule (us-28-vNext, shallow)"
5) Verify
6) If you need to clean a previous failed attempt
git submodule deinit -f -- external/MSDyn365BC 2>$null
git rm -f external/MSDyn365BC 2>$null
Remove-Item -Recurse -Force ".git\modules\external\MSDyn365BC" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "external\MSDyn365BC" -ErrorAction SilentlyContinue
Remove-Item ".gitmodules" -ErrorAction SilentlyContinue
If you cloned the repo and the submodule folder is empty¶
Submodules are not downloaded automatically on git clone. Run this once after cloning:
This pulls the BC source at the exact commit the submodule points to.
Add it to your workspace¶
Open workshop.code-workspace and add the new folder so your IDE and agent see it side-by-side with app/ and test/:
Watch it in action¶
Once the submodule is in place and visible in your workspace, the agent has eyes on real BC code. You're ready to use that to design the extension.