delivery-settings.json

The delivery of an Access project: the version of the application, its targets and the release packages a delivery carries along. wkl-office deliver and the group Delivery of the add-in read it.

delivery\delivery-settings.json in the project folder, under version control:

{
  "format": 2,
  "version": "1.4.0",
  "packages": {
    "components": "%WKL_PACKAGES%\\Wkl.Forms.ObjectLibrary\\2.0.0",
    "json": "%WKL_PACKAGES%\\Wkl.Office.JSON\\2.0.0",
    "bootstrapper": "%WKL_PACKAGES%\\Wkl.Bootstrapper\\3.1.0"
  }
}

Beside it, one file per delivery profile, delivery\<profile>.profile.json:

{ "format": 1, "configuration": "Release" }

One file per project, with what all delivery profiles share and the SDK cannot read from the sources: the version the delivery carries and where the release packages lie on the build machine. Each profile is a file of its own (delivery profiles). The starter's own settings (files, registry, shortcuts, conditions, the share it reads from) are in its project file per profile, delivery\<profile>.bootstrapper.json, edited with Bootstrapper Manager. A file in format 1 lists the delivered modes as targets instead; it stays valid.

It is not the delivery.json that WKL Bootstrapper writes beside a signed delivery in the source folder.

Package paths may hold environment variables (%WKL_PACKAGES%) and may be relative to the project folder, so one file serves every machine whose packages lie elsewhere. Unknown entries are refused; a default is left out when the SDK writes the file.

With "format": 2, delivery-settings.json keeps only what all targets share (version, publisher, supportEnd, requirePublisher, packages) and has no targets. Each target is a file of its own, delivery\<name>.profile.json, like a publish profile in Visual Studio; deliver and the add-in take the profiles in the order of their names.

{
  "format": 1,
  "configuration": "CustomerA",
  "starterName": "customers.exe"
}

• The name of a profile is its file name: letters, digits, spaces and - _ ., at most 64 characters, not starting or ending with a space or a dot, and no device name of Windows (CON, NUL …). deliver -p <name> delivers one profile.
• Several profiles may deliver the same mode, for example one per customer, each with its own configuration (connection profile) and folder. Whether an ACCDE is delivered follows the mode, as in format 1: Development delivers an ACCDB; Accde of the configuration does not change that.
• Format 1 stays valid. Its targets are read as profiles named after their mode and built in the configuration of that name when the project file has one, otherwise with the settings of the project; the mode is the target's own. The SDK does not rewrite a file of format 1 into format 2 by itself; Project Properties of the add-in writes format 2 once the delivery is changed there (use the Access add-in).

• Which libraries go along is read from the references of the project (source\references.json), by the GUID of their type library: WKL Forms Object Library and WKL Office JSON. References to Access, DAO, VBA or Office belong to Access and are not delivered.
• A package is checked before anything is built: both bitnesses must be there (x86\<dll>, x64\<dll>) and its release (from x86\registration.json, else the folder name) must not be older than the reference. wkl-office deliver --dependencies lists the result.
• The runtime and the drivers are not read from the sources: the SDK cannot tell whether the PCs have .NET or a driver installed already, so they go along only when packages names them. When the starter's project file is written from a template, the templates dotnet and odbc are added; the odbc template names an example driver, which the developer replaces in Bootstrapper Manager with the drivers named here.
• A chosen delivery folder is emptied only when an earlier delivery wrote it (it is empty or holds deploy\app-manifest.json); any other folder - a share, the project folder by mistake - is refused and left as it is.
• bitness: any builds twice. The first build compiles the code as a check; a compile error ends the delivery with exit code 4, as in build. The second build loads the same sources without compiling them and is the database that is delivered, so it carries no compiled state of the building Access. Its startup properties are those of the mode, as in an ACCDE. Because the delivery is an ACCDB, its code is readable and can be changed; deliver an ACCDE per bitness instead when that is not acceptable. The VBA code must be valid in both bitnesses (PtrSafe and LongPtr in Declare statements). app-manifest.json states "bitness": "any".
• Product key per target: Production is delivered as the project name, Administration as the name with Admin, Development with Dev, so the copies on a user's PC never replace each other. Delivery profiles of the same mode share the product key; deliver them to different computers.

A delivery of production only, with packages beside the project:

{
  "format": 1,
  "version": "2.0.0",
  "targets": [ { "mode": "Production" } ],
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.0.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0"
  }
}

A delivery to a share, with a renamed starter, a private runtime and the OData driver:

{
  "format": 1,
  "version": "2.0.0",
  "targets": [ { "mode": "Production", "output": "\\\\server\\apps\\Demo", "starterName": "demo.exe" } ],
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0",
    "dotnet": "..\\packages\\dotnet-10",
    "odbc": [ { "driver": "Wkl OData", "folder": "..\\packages\\WklOData" } ]
  }
}

A delivery for two customers in format 2, each built in its own configuration (delivery\delivery-settings.json, then delivery\Customer A.profile.json and delivery\Customer B.profile.json):

{
  "format": 2,
  "version": "2.0.0",
  "packages": {
    "components": "..\\packages\\Wkl.Forms.ObjectLibrary\\2.1.0",
    "bootstrapper": "..\\packages\\Wkl.Bootstrapper\\3.1.0"
  }
}

{ "format": 1, "configuration": "CustomerA", "output": "\\\\server-a\\apps\\Customers" }

{ "format": 1, "configuration": "CustomerB", "output": "\\\\server-b\\apps\\Customers" }

The configurations in the project file set the mode and the connection profile of each customer:

<PropertyGroup Condition="'$(Configuration)' == 'CustomerA'">
  <Accde>true</Accde>
  <AppMode>Production</AppMode>
  <ConnectionProfile>PROD-A</ConnectionProfile>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'CustomerB'">
  <Accde>true</Accde>
  <AppMode>Production</AppMode>
  <ConnectionProfile>PROD-B</ConnectionProfile>
</PropertyGroup>

• Project folder – which file goes where and what is versioned
• Build configurations and delivery profiles – what a configuration and a profile decide
• Deliver an application from the SDK
• Command-line reference: deliver, msi