Build configurations and delivery profiles

graph LR
  P[Project file .acproj] --> K[Build configuration]
  K --> M[Mode of the application model]
  K --> V[Connection profile]
  K --> O["Output folder build\configuration"]
  A[Delivery profile] -->|is built in| K
  A --> L["Delivery folder build\Delivery\profile"]
  A --> S[Starter]

Why two terms for what looks like one thing? Because building and delivering answer different questions. A build configuration decides how the database is built. A delivery profile decides what goes to whom, and where. Visual Studio draws the same line: the configuration (Debug, Release) drives the build, and a publish profile decides where and how the result is published. A profile is always built in a configuration, but a configuration is useful without any profile too, such as Debug while you develop.

• A build configuration belongs to the project file. It decides whether an ACCDE is made, which mode the application model gets and which connection profile links the tables. Its database goes to its output folder <BaseOutputPath>\<configuration>.
• A delivery profile is a file of its own, delivery\<name>.profile.json. It names the configuration it is built in, the delivery folder, the starter and whether it targets the Access runtime. Without a delivery folder of its own, its delivery goes to <BaseOutputPath>\Delivery\<name>, with the name in lower case.
• The mode (Development, Administration, Production) is a property of the configuration. A profile delivers the application in the mode of its configuration, and several profiles may share a mode.
• What all profiles share, the version and the release packages, is kept once in delivery\delivery-settings.json.

Every project has Debug and Release; the project file adds others in Configurations or in a property group of their own (project file). A configuration sets three values, and takes the project's value for any it leaves out:

You choose the configuration with --configuration on the command line (default Debug) or in the drop-down Configuration of the add-in; Build and reopen, Rebuild and reopen and Validate then work with it.

A profile answers what a delivery contains: the database of its configuration, its manifest, the WKL libraries and the starter with its project file delivery\<name>.bootstrapper.json. deliver builds each profile in its configuration and writes the result to the profile's delivery folder; deliver -p <name> delivers a single profile (delivery-settings.json).

A profile needs a configuration that sets a mode, because the mode decides what is delivered: Development delivers an ACCDB, Administration and Production deliver an ACCDE, whatever Accde of the configuration says. A profile with bitness: any delivers an ACCDB that runs in 32-bit and 64-bit Office, in every mode (delivery-settings.json).

Two customers get the same application, each with a database connection of its own. That takes two configurations with the mode Production and a connection profile each, and two profiles that build one of them each:

You keep developing in Debug; that configuration needs no profile.

• The project file: the configurations and their values. In the add-in you edit them in Project Properties (use the Access add-in).
• The profile files and delivery-settings.json: the delivery, also in Project Properties or by hand (deliver an application from the SDK).
• The SDK settings: only the defaults for new projects, such as which configurations they get (SDK settings); they do not change existing projects.

A delivery-settings.json in format 1 lists one target per mode instead of profiles. It stays valid: each target is read as a profile named after its mode. As soon as you change the delivery in Project Properties, the add-in writes it in format 2 (format 1 and format 2).

• Project folder – which file goes where and what is versioned
• Project file – configurations and their properties
• delivery-settings.json – profiles and shared settings
• Deliver an application from the SDK