Microsoft Access development tools
Color scheme: Riviera
Riviera
Light
Dark

Office SDK · for Access application developers

Put Access applications in Git and build them from source

Every form, query, and module as a text file. The ACCDE comes from a commit—not from whichever copy was saved last.

You keep designing in Access. The SDK moves the application between Access and its text sources and builds the database from them—on the command line, from the Access ribbon, or in your build pipeline.

Tutorial: from an ACCDB to your first commit When one file stops being enough
  1. Design in Access
  2. Text sources in Git
  3. ACCDE from a commit

You design in Access, and the SDK writes your changes to the sources. Builds come from a defined state of those sources.

The situation

An Access application is one file. That works—until four questions come up.

Forms, reports, queries, code, tables, and settings all live in a single binary file. As long as one developer works on one copy, that's fine. Add a second developer, a bug in production, or an auditor's question, and it isn't.

  • What changed? You can't compare two copies of an ACCDB line by line. To find what broke the application, you open old copies side by side.
  • Who's working on it? Two developers can't merge their work into one file. One copies the other's forms over by hand—and a change saved in the wrong copy disappears 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 a script check it? Nothing tells a script whether the application is complete and compiles—only opening it in Access does.

Why not SaveAsText or an add-in?

Access can export single objects as text—not the whole application

Plenty of teams already export their objects with SaveAsText and read them back with LoadFromText. For forms, reports, and modules, that works. But Microsoft doesn't document these methods, and they leave out tables, data, references, and database properties—so you can't rebuild a complete application from them alone.

Many teams go a step further with the open-source msaccess-vcs-addin: it exports forms, queries, modules, and more from the Access ribbon and can rebuild a database from source. For a single developer, that's often all it takes. The SDK adds what a team and a build pipeline need on top: a command line and MSBuild integration with defined exit codes, a check that runs before Access starts, and a sync that stops instead of overwriting when an object was changed on both sides.

The SDK keeps the entire application as source, including table schemas, seed data, references, and properties. If your application is already kept as text with another tool—DATEC Access SDK, the Forms Object Library build tool, or the Extensions add-in—wkl-office migrate converts the project once and only reads the old one. Coming from another tool

With the SDK

The application as text: readable, mergeable, buildable

The four answers build on each other. Once the application is text, you can read its changes; then 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 runs without anyone at the keyboard.

The repository is the source of truth. ACCDB and ACCDE files are build output and never get committed.

Customers/  Customers.acproj  source/    forms/frmCustomers.form.txt    queries/  modules/    classes/  reports/    tables/tblCountries.table.json    data/tblCountries.jsonl    references.json    application/properties.json  build/   built, not committed    Debug/Customers.accdb    Release/Customers.accde
The tutorial's Customers project after the export: one text file per Access object, table schemas as JSON, seed data as JSON Lines.
  • What changed? git log shows when, wkl-office diff shows the lines, and wkl-office changes lists everything that differs between the open database, the sources, and the last commit.
  • Who's working on it? Everyone commits text sources; git merges them and shows conflicts per file. A merge without conflicts isn't checked for meaning—build the result and test merged forms 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. The same sources built with the same Access, references, and code page give the same objects, tables, data, and settings; the file itself isn't byte-identical.
  • A script can check it. wkl-office check finds invalid sources, missing references or ODBC drivers, the wrong bitness, and passwords written into the sources—before Access even starts.

One development cycle

Access stays the designer: the SDK drives the Access installed on the machine and doesn't replace the form or report designer.

  1. Build the working database

    From the sources alone, to build/Debug/Customers.accdb.

    wkl-office build Customers.acproj

  2. Change it in Access

    Design a form, edit a module, save—the way you always have.

  3. See what changed

    The changed objects with the next step for each, plus the lines of one form.

    wkl-office changes Customers.acprojwkl-office diff Customers.acproj form:frmCustomers

  4. Commit

    Checks again, exports the changed objects to the sources, and commits them. Nothing is pushed until you run wkl-office push.

    wkl-office commit Customers.acproj -m "Customer form: new field for the VAT ID"

  5. Release

    On any machine with the same Access and the same references, the ACCDE is built from exactly this commit.

    wkl-office build Customers.acproj -c Release

Changes from the other side—a teammate's commit, an edit in Visual Studio Code—come 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 wins.

The VBA editor with the Office SDK: module code, the work area, and the terminal showing the result of wkl-office test
In the VBA editor: the SDK toolbar, with its work area below. The terminal shows a test run with wkl-office test: two test procedures, both passed. How to test an application

Works with the tools you already use

  • In Access—the same steps on a tab of the Access add-in on the ribbon.
  • In Visual Studio Code—sources you edit there come back into the open database with wkl-office sync.
  • In your build pipeline—dotnet build runs the same build through MSBuild; every command returns a defined exit code and, with --json, a JSON object.
  • With Git or Subversion—Subversion works through svn.exe but hasn't been proven in an acceptance run yet.

Status and limits

Is the SDK a fit for your project?

In development
It's a fit if you develop on Windows 11 with 32-bit or 64-bit Microsoft Access from Microsoft 365 and want to keep your sources in Git or Subversion. Check these points first:

  • Access 2016 through 2021, Windows 10, or the Access Runtime only: the current release doesn't support these environments.
  • Builds run in a signed-in Windows session with Access, not in a service. Signing in the build account and keeping its session alive is up to your build system.
  • Check what the export leaves out: parts the SDK doesn't handle aren't exported. Run wkl-office roundtrip once on every new project.
  • It builds, it doesn't deploy: getting the application onto users' PCs is the job of Bootstrapper. The SDK doesn't version the data in production databases.

Requirements and limits in detail

Start here

  • Install the SDKA folder, not a setup: Windows 11 with the full Microsoft Access, the .NET 10 runtime, and git on the PATH.
  • TutorialFrom an existing ACCDB to your first commit, using a real database.
  • How-to guidesCommit from Access, use the add-in, work in Visual Studio Code, build with dotnet build, test, translate.
  • Command-line referenceEvery command, option, exit code, and JSON field.
  • TroubleshootingA dialog in Access, unsaved work, a roundtrip with differences, and more.
  • Source layout and formatsWhere each part of an Access application lives in the sources, and in which format.

Want to know what the SDK includes and what your development machine needs? The product page covers features, requirements, and limits.

See the product page

Prefer to talk first? We'll look at your project with you · All tools for Microsoft Access · Product overview