WKL Bootstrapper: per-user installer and starter for Access applications

The WKL Bootstrapper delivers a new release of an application to every user without administrator rights and without a visit to each PC. The user starts one EXE; it installs the version the publisher delivered into the user's profile, registers everything it needs for that user, and starts it. It is made for Access front ends built with WKL Forms Object Library, and it starts any other program or document the same way.

The product is called the Bootstrapper; its program is Wkl.Bootstrapper.exe, and the pages call it the starter for short, because that is what the user sees it do.

Up to release 2.3.1 the product was called WKL Access Bootstrapper, and up to release 2.4.1 its program was Wkl.Access.Bootstrapper.exe. A folder that still holds the program under that name keeps working: where no starter is named, the starter takes Wkl.Bootstrapper.exe and, if it's missing, the earlier name.

Supported configuration: Windows 11 with 32-bit or 64-bit Microsoft Access (Microsoft 365). Windows 10 and computers that restrict programs in the user's profile with AppLocker or Windows Defender Application Control are not supported in this release. See Limits for what the starter does not do at all.

An Access front end is a file, and every user works with an own copy: Microsoft recommends a split database in which “each user interacts with the data by using a local copy of the front-end database”, because only the data then crosses the network and file corruption “is usually limited to the copy of the front-end database that the user had open” (Split an Access database).

That copy is not all an application needs. With every release:

• each user's copy has to be replaced, while some users still have the old one open;
• the WKL Forms Object Library (or other ActiveX and COM components) have to be registered in the bitness of the installed Office;
• the folder has to be a trusted location, or Access does not run the code;
• ODBC drivers, data sources and the .NET runtime have to be present.

Done by hand, that is a visit to every PC, usually with administrator rights. A faulty release cannot simply be taken back, and nobody knows afterwards what was installed where.

The starter takes the model of ClickOnce (per user, without administrator rights, updates from the publisher's source) and the thoroughness of Windows Installer (a record of every file and registry value, counted shared components, rollback, removal under Apps). The IT installs only the starter itself, once; every later release reaches the users through it.

graph TD
    U["User starts Wkl.Bootstrapper.exe"] --> P["Read the project file (bootstrapper.json, or the file /RUNCFG names)"]
    P --> S["Resolve it against the source (files, version, registry, start target)"]
    S -- "source not reachable or delivery not trusted" --> I["Start the installed version"]
    S --> C["Check the conditions (Access, .NET, ODBC, files, registry, programs)"]
    C -- "not met" --> E["Error window with code and diagnosis"]
    C --> T
    subgraph TX["One transaction"]
        T["Install the version: files, components, drivers, registry, file types, shortcuts, INI, trusted location, entry under Apps, afterInstall actions"]
        J[("installer.db - journal of every step")]
        T -- "records each step" --> J
    end
    T -- "a step fails" --> R["Roll back every step in reverse order"]
    T --> K["Remove versions beyond keepVersions"]
    K --> G["Start the target (a program, a document by its file type, or Access with the database)"]

• Project file (bootstrapper.json next to the EXE, or another .json file in the same folder named with /RUNCFG <file>): what the starter installs and starts - files, registry values, shortcuts, file types, an INI file, actions, conditions and the start target. Contract: The project file (format 2).
• Source (the delivery): the folder or share the publisher fills. A start reads it and never writes to it.
• Version: each delivered version gets a folder of its own in the profile; files there are placed once and never replaced.
• Shared components: WKL Forms Object Library, ODBC drivers, a private .NET runtime and other parts outside a version's folder are kept per release and counted per product version; they stay as long as any product of the user needs them.
• Installer database (%LOCALAPPDATA%\WKL\Installer\installer.db, one per user): the record of every product, version, component and resource, and the journal of the running installation.
• Codes: every start ends with a code - 0 started; 1x configuration, 2x Access, 3x prerequisites, 4x the installation, 5x trust, 6x the start. The same number appears in the error window, in the diagnosis and as exit code.

Everything is written below the user's folders and HKEY_CURRENT_USER; the starter never asks for elevation. Details: The installer.

The starter has three kinds of readers; each has its own way in.

You build the application and want it on the users' PCs.

1. Write a project file from templates: How to: Create a project from templates.
2. Fill in what it installs and starts - an Access application as in How to: Deliver an application with the bootstrapper, any other program as in How to: Start any program with the starter.
3. Check the file with Wkl.Bootstrapper.exe /check <file> and try it with /whatif <file>, which reports every check and what a start would install, without changing anything.
4. When needed: Deliver an Access application to 32-bit and 64-bit Office, Deliver a private .NET runtime, Publish a signed delivery, How to: Start an application without a lasting installation.

The project file can also be edited in the WKL Bootstrapper Manager, a separate Access application that runs the same checks and builds the MSI; it is documented in the “WKL Bootstrapper Manager user guide” of the WKL Bootstrapper Manager documentation.

You manage the PCs and decide what may be installed. The starter needs no administrator rights for any release; only the starter itself is installed once, as a Windows Installer package built from the project file: How to: Roll out the starter with an MSI. What the starter writes on a PC is listed in The installer.

You look after one application for its users.

• /settings opens the settings window: whether the application can start, the installed versions (start an earlier one, copy one again, remove old ones), the registration of the components, the diagnosis, the log, and the entries of the project file an application administrator may change.
• /diagnose (/diagnose /json) reports what a start would find, without changing anything; /list (/list /json) shows the installed versions and components with their number of users.
• /repair installs what is missing without starting; /uninstall removes the product.
• The log lies in %LOCALAPPDATA%\WKL\<product>\Logs\bootstrapper.log.
• A failed start shows a code; Error codes of the starter has one page per code with the cause and the resolution.

All commands and exit codes: The installer.

• The starter installs nothing that needs administrator rights: no system-wide drivers, no Access Runtime, no machine-wide registrations. These are prerequisites the IT provides; the starter checks them and reports a missing one with its code.
• It does not build the application; an Access application is built with the WKL Office SDK.
• Two starters of the same Windows user installing at the same moment are not serialized; start one at a time.
• A source over HTTP or HTTPS is not supported; the source is a folder or a share.
• The signature of a delivery does not cover the programs actions run; see Signed deliveries for what it does not cover.
• More in Limits of the installer.

Only relevant if users are already served by an earlier starter.

• StarterPro, the predecessor of this starter with its configuration StarterPro.config.xml: /import-starterpro converts the configuration into a project file. See How to: Move from the former starter.
• Starter 1.0 (project files of format 1): still read and started. 2.x takes over what 1.0 placed and removes it like its own parts (Taking over the starter 1.0). For deliveries that still run the 1.0 way: What the starter writes and reports and How to: Remove an application from a PC.

• The project file (format 2) – every entry, the placeholders, actions and conditions
• The installer – transaction, counting, release rule, commands, the installer database
• Error codes of the starter
• Security and manufacturer obligations – reporting a vulnerability, obligations under the Cyber Resilience Act and towards NIS 2 entities, path to conformity
• tools\Export-ComRegistration.ps1 in the release folder captures the registration of a COM server as registration.json on the publisher's computer; the starter writes it for the user instead of running the server's own registration.