How to: Deliver an application with the bootstrapper

Deliver an Access application built with WKL Forms Object Library so its users start it with one click, always in the current version, without an installer and without administrator rights.

Requires WKL Forms Object Library 1.51 or later (the build tool's deploy), WKL Bootstrapper 1.0 or later.

This page shows the project file in format 1, which the starter still reads. Start a new project in format 2, most easily from templates.

Solution overview

The build tool of WKL Forms Object Library writes the delivery: the database and its app-manifest.json.
The delivery goes to a share, with the WKL components of the release beside it.
The starter - Wkl.Bootstrapper.exe and bootstrapper.json - points at the share; users start the EXE.

Implementation

Build the delivery. In the project file of the build tool, name the application model and the delivery:
```
{
  "name": "Customers",
  "appModel": "src/app/app-model.json",
  "deploy": { "version": "1.4.0", "targets": [ "Production" ] }
}
```
Build-AccessApp.ps1 writes deploy\production with Customers.accde and app-manifest.json (product, version, file, size, SHA-256, bitness, runtime, required WKL release).
Put the delivery on the share. Copy the database first and app-manifest.json last, for example to \\server\apps\Customers\production. Users need read access only.
Add the WKL components when the users' PCs do not have them registered: copy the folders x86 and x64 of the WKL release package to \\server\apps\Customers\production\components\x86 and ...\x64.
Write the starter. A folder with Wkl.Bootstrapper.exe and bootstrapper.json, on the share or copied to each PC:
```
{
  "format": 1,
  "product": "Customers",
  "displayName": "Customer Management",
  "source": "\\\\server\\apps\\Customers\\production",
  "components": "components",
  "odbcDrivers": [ "ODBC Driver 18 for SQL Server" ],
  "keepVersions": 2
}
```
Every entry is described in the project file reference. A logo of your own goes next to the EXE and into branding.logo; without one, the windows show the logo of The White Knight Labs.
Give the users a shortcut to Wkl.Bootstrapper.exe. Check the setup once with Wkl.Bootstrapper.exe /diagnose on a user's PC: the first line 0 Ok means a start will succeed.
Deliver an update by building the new version and copying it to the same folder (database first, app-manifest.json last). At their next start users get the new version in a folder of its own; a copy still open in Access is not touched.

Expected result

The first start of a user copies the version into %LOCALAPPDATA%\WKL\Customers\Frontends\1.4.0, registers the WKL components for the user if needed (the start window shows as a splash for at least splash.duration, default 3 seconds, and closes once Access is visible), makes the folder a trusted location and opens the application in Access - without a security warning. Later starts open the copy at once. When something is missing, the error window names it with a code (see Error codes of the starter).

Remarks

Going back. While a new version fails, a user (or support) opens Wkl.Bootstrapper.exe /settings, page Application, selects the version marked “started last” and chooses Start this version.
The copy is the user's. Access writes into the database it opens, so the copy is checked against the delivery only when it is placed. Copy again in the settings places it fresh from the delivery.
Passwords never go into the starter. INI values that look like secrets are refused; connections belong to the application (Linked Tables Manager, application model).
ODBC drivers for the user only. A driver installed only for the user (DLL in the profile, a user DSN naming it by path, no entry under ODBCINST.INI) is checked through its data source: "odbcDataSources": [ "MyDsn" ] instead of odbcDrivers (from 1.0.1).
Bitness. One delivery serves one bitness of Access when it is an ACCDE; see How to: Deliver an Access application to 32-bit and 64-bit Office.
Supported: 32-bit and 64-bit Office. Over a slow connection the first copy takes accordingly long; the progress window shows while it runs.

Deliver the administration version too

The build tool writes deploy\administration next to deploy\production when the application model has both modes. A starter starts the one folder its source names, so the administration version gets a starter of its own:

Copy deploy\administration to its own folder on the share, for example \\server\apps\Customers\administration, with the components below it as for production.

Write a second starter folder with Wkl.Bootstrapper.exe and a bootstrapper.json whose source names that folder and whose product is different, for example CustomersAdmin:

{
  "format": 1,
  "product": "CustomersAdmin",
  "displayName": "Customer Management (Administration)",
  "source": "\\\\server\\apps\\Customers\\administration",
  "components": "components"
}

Give the shortcut only to the administrators.

The copies lie per product in %LOCALAPPDATA%\WKL\<product>\Frontends\<version>. With the same product and the same version both deliveries would replace each other's copy at every start. The administration version asks for full Access in its app-manifest.json (runtime: false): the starter opens it without /runtime, and on a computer with only the Access runtime it stops with code 22 (see The application needs full Access).