WKL Office SDK: source control and builds for Microsoft Access

The WKL Office SDK lets you keep a Microsoft Access application in git or Subversion and review changes per form, query and module, and it builds the ACCDB or ACCDE from a defined state of the sources instead of from whichever database file was saved last. You still design forms, reports and VBA code in Access; the SDK moves them between Access and the text sources and builds the database from them.

Supported configuration: Windows 11 with 32-bit or 64-bit Microsoft 365 Access. Access 2016 to 2021, Windows 10 and building with only the Access Runtime are not supported in this release. What changed in each release is in CHANGELOG.md of the release package.

The situation without it

An Access application lives in one binary file: forms, reports, queries, code, tables and settings together. As long as one developer works on one copy, that is enough. It stops being enough as soon as one of these questions comes up:

What changed? Two copies of an ACCDB cannot be compared line by line. To find what broke the application, old copies are opened side by side.
Who works on it? Two developers cannot merge their work in one file. One copies the other's forms by hand, and a change saved in the wrong copy is lost without a trace.
What goes to the users? The release is the developer's own ACCDB, compiled to ACCDE with whatever it happened to contain that day: test forms, an old link, an unfinished module.
Can it be checked without a person? Nothing tells a script whether the application is complete and compiles, except opening it in Access.

Access itself can write single objects as text (SaveAsText, LoadFromText), but Microsoft does not document these methods, and they leave out tables, data, references and database properties. A complete application cannot be rebuilt from them alone.

What changes with the SDK

The four answers build on each other: once the application is text, its changes can be read; once changes can be read, several people can work on it; once the sources are complete, the database can be built from them; and once a build is one command, it can run without a person.

Question	With the SDK
What changed?	Every form, report, query, macro and module is one text file. `git log` shows when it changed, `wkl-office diff` shows the lines, and `wkl-office changes` lists everything that differs between the database open in Access, the sources and the last commit.
Who works on it?	Each developer commits the text sources; git merges them and shows conflicts per file. A merge without conflicts is not checked for meaning: build the result and test merged forms and reports in Access. Pull requests show forms, queries and modules as text for review.
What goes to the users?	`wkl-office build -c Release` builds the ACCDE from the committed sources, not from a developer's working copy. The same sources built with the same Access, references and code page give the same objects, tables, data and settings; the file itself is not byte-identical (what is reproducible).
Can it be checked without a person?	`wkl-office check` finds invalid sources, missing references or ODBC drivers, wrong bitness and passwords written into the sources before Access starts. Every command returns a defined exit code and, with `--json`, one JSON object; `dotnet build` runs the same build from MSBuild.

How it works

graph TD
    A[Access: design forms, reports, code] -->|wkl-office export / commit| S[Sources in git or svn]
    S -->|wkl-office build| B[build/Debug/App.accdb]
    S -->|wkl-office build -c Release| R[build/Release/App.accde]
    B -->|open in Access| A
    S -->|CI: check, build, roundtrip| C[Exit code + JSON]

The repository is the source of truth; the ACCDB and ACCDE are build results that are never committed.

Project file (<name>.acproj): MSBuild XML that names the application, its source folder and its build configurations (reference).
Sources (source/): one file per object, table and model, in a fixed layout (reference). Objects are kept as Access writes them, cleaned of values that change on every save; tables as JSON schema, seed data as JSON lines, plus references, database properties, theme, images, ribbons and the models of WKL Forms Object Library.
Configurations (Debug, Release, own names): decide whether an ACCDE is made, which mode of the application model it is made for, and which connection profile links the tables.
Access stays the designer. The SDK automates the Access installed on the machine out of process. It does not replace the form and report designers.

One development cycle

A developer who has the project checked out:

Build the working database from the sources: wkl-office build Customers.acproj writes build/Debug/Customers.accdb.
Change the application in Access as always: design a form, edit a module, save.
See what changed: wkl-office changes Customers.acproj lists the changed objects with the next step for each; wkl-office diff Customers.acproj form:frmCustomers shows the lines.
Commit: wkl-office commit Customers.acproj -m "Customer form: new field for the VAT ID" checks again, exports the changed objects into the sources and commits them. Nothing is pushed until wkl-office push.
Release: on any machine with the same Access and references, wkl-office build Customers.acproj -c Release builds the ACCDE from that commit.

Changes that arrive from the other side (a colleague's commit, an edit in Visual Studio Code) are brought into the open database with wkl-office sync. An object changed on both sides is never overwritten: the run stops until you decide which side to keep. The tutorial walks through this cycle with a real database, the Access add-in offers the same steps on a ribbon tab inside Access.

Requirements and limits

Windows 11 with the full Microsoft Access installed and activated for the user who builds, the .NET 10 runtime, and git (or svn.exe) on the PATH. Details: Install the WKL Office SDK.
Builds need an interactive Windows session with Access, not a service. Access runs hidden, every step has a time limit, and a dialog Access shows is canceled and reported instead of hanging the run. Signing in the build account and keeping its session is the job of the build system.
What the export leaves out. Values Access writes anew on every save and state of a machine or user are removed on purpose. Parts of an application the SDK does not handle (some object kinds, unknown table, field and database properties, linked tables outside the Linked Tables Manager) are not exported either; properties are reported as warnings, object kinds are not. Check a new project once with wkl-office roundtrip and read What the export does not keep.
The SDK does not deploy the application to user PCs (that is the WKL Bootstrapper) and does not version the data of production databases.

Next step

Install the WKL Office SDK
Tutorial: Put an Access application under source control – from an existing ACCDB to the first commit

Coming from another tool

Only relevant if your application is already kept as text with another tool; wkl-office migrate converts such a project once, and the old project is only read.

DATEC Access SDK (msaccess-sdk), a separate tool that also keeps Access objects as text: Migrate a project of the DATEC Access SDK.
Build tool of WKL Forms Object Library (access-app.json), the predecessor of this SDK for applications built with WKL Forms Object Library: Migrate a project of the build tool.
WKL Extensions add-in (WklExtensions.accda), whose menu opened the designers of WKL Forms Object Library: Move from the WKL Extensions add-in.