Project file reference: .acproj

<Project>
  <PropertyGroup>
    <SchemaVersion>2</SchemaVersion>
    <AssemblyName>Customers</AssemblyName>
    <SourceRoot>source</SourceRoot>
    <BaseOutputPath>build</BaseOutputPath>
    <DeliveryRoot>delivery</DeliveryRoot>
    <Configurations>Customer</Configurations>
    <TargetAccess>any</TargetAccess>
    <Template>template</Template>
    <Accde>false</Accde>
    <AppMode></AppMode>
    <ConnectionProfile>DEV</ConnectionProfile>
    <Finish>FinishBuild</Finish>
    <Test>AllTests</Test>
    <ControlBlocks>control-blocks</ControlBlocks>
    <NeutralLanguage>sl</NeutralLanguage>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <Accde>true</Accde>
    <AppMode>Production</AppMode>
    <ConnectionProfile>PROD</ConnectionProfile>
  </PropertyGroup>
  <ItemGroup>
    <TablePolicy Include="tblCountries" Policy="SeedData" />
    <TablePolicy Include="tblCache" Policy="Ignore" />
  </ItemGroup>
</Project>

The project file names an Access application, where its sources are and how each build configuration builds it. It is MSBuild XML, so dotnet build reads the same file; every tool of the SDK reads it the same way.

A PropertyGroup with Condition="'$(Configuration)' == '<name>'" overrides Accde, AppMode and ConnectionProfile for that configuration; the other properties are the same for all configurations (see Remarks).

By default, the sources are in fixed locations below SourceRoot (Source layout and formats). Source items put a kind of source somewhere else: each item includes the files that its Include attribute names, relative to the folder of the project file.

<ItemGroup>
  <AccessForm Include="ui\pages\*.form.txt;ui\dialogs\*.form.txt" Exclude="ui\pages\old\**" />
  <AccessTable Include="db\tables\*.table.json" />
  <AccessReferences Include="db\references.json" />
</ItemGroup>

Rules:

• Include and Exclude take files or patterns, several separated by ;, with the MSBuild wildcards: ? matches one character, * any number of characters within one file or folder name, and ** any number of folders. Case doesn't matter. The base folder of a pattern is the folder before its first wildcard: for ui\pages\*.form.txt, it's ui\pages.
• An item includes only files with the file name extension of its kind: under AccessForm, ui\pages\* includes the .form.txt files there, not the page settings of a report next to them.
• A kind without items stays in its default location. A project without source items is read exactly as before.
• If one item names a file explicitly and a pattern of another item also matches it, the file belongs to the item that names it. Two patterns that match the same file are an error: name the file explicitly in one item, or narrow the patterns.
• check and every command that reads the sources report these as errors:
  • an item that matches no file;
  • a file with the extension of an object, a table or table data that no item includes, below SourceRoot or below the base folder of a pattern (to leave a file out on purpose, exclude it with Exclude);
  • two files that hold the same object.
• The folders build, obj, .git and .vs in the project folder and the folder of BaseOutputPath are never searched.
• The export writes every object back to the file it came from. A new object goes to AccessDefaultFolder<Kind>; if that isn't set, to the base folder of the kind's first item; otherwise, to its default location.
• Paths in messages (check, roundtrip) are relative to the folder of the project file.

• What is not in the file. References (in priority order) and database properties (typed) are sources of their own, source/references.json and source/application/properties.json, so an export never rewrites the file a person edits.
• Other elements are left to MSBuild: the SDK reads only the properties and items above, so the file may hold properties of its own and the Import of the MSBuild targets.
• Conditions. A property group of SDK properties takes only the form '$(Configuration)' == '<name>'; another condition is refused. In a configuration group the SDK takes Accde, AppMode and ConnectionProfile; another SDK property there (SchemaVersion, AssemblyName, SourceRoot, BaseOutputPath, DeliveryRoot, Configurations, TargetAccess, Template, Finish, Test, ControlBlocks, NeutralLanguage, AccessDefaultFolder<Kind>) is refused, and properties of your own are left to MSBuild. Item groups with SDK items take no condition.

The application model of WKL Forms Object Library (application/app-model.json) wants other startup properties for each mode: development (an ACCDB), administration (an ACCDE in the full Access) and production (an ACCDE in the runtime) - for example no bypass key and no special keys in production. The application corrects them itself when it calls EnsureApplication at its start. With AppMode, the build writes them into the ACCDE right away, so the delivered file is right from its first opening, before any code runs. AppIcon is removed from the ACCDE because it names a file of the build machine; the application writes the icon of the user's machine at its first start. The ACCDB stays a development database. check refuses an unknown mode and warns when the sources hold no application model or the configuration makes no ACCDE.

The template's objects, tables (with their policies), relationships, references and properties join the application's. A source of the application replaces the template's of the same name; the application's references come first; a property of the application wins. Theme, models and the finishing function come from the template when the application has none. A template that names a template itself is refused. export writes nothing the template alone contributes; to change an object of the template for one application, copy its file into the application's sources.

To build on a template that several applications share, keep it out of the application's repository: set <Template> to the template's folder name and the environment variable WKL_ACCESS_TEMPLATES to the folder that holds it (several folders separated by ;). A new version of the template then arrives with the next build.

The build runs it with Application.Run after the models, before the last compile and the ACCDE, for steps the SDK does not know (filling Generated tables, for example). It returns "" or "OK" for success; any other text stops the build with that text. An error it does not handle opens the runtime error dialog of VBA, which the build cancels and reports. It may run for at most 5 minutes; then the hidden Access of the build is ended and the build fails. It should follow the VBA error skeleton of an automation helper: handle its errors and return a text instead of raising. check refuses a name that is no public function of a standard module.

wkl-office test calls it with Application.Run in the hidden Access of the run. It returns the names of the test procedures, public procedures (Sub or Function) of standard modules without arguments, as an array (Array("Orders_Create", "Orders_Delete")) or as one text with the names separated by commas. A project that names a test function gets the test module WklTest of the SDK in every build, also when its sources have none; a module WklTest in the sources is always replaced by the SDK's, and the next export writes the SDK's into the sources. check refuses a name that is no public function of a standard module. See Test an application.

A rectangle in a form whose Tag is wkl:<Kind> (wkl:Grid, wkl:ActionBar …) is replaced, when the form is loaded, by the control block <Kind>.control.txt, with the rectangle's name, position, size and anchors. The release package of WKL Forms Object Library ships the blocks in control-blocks. check names every placeholder whose block is missing. The export writes the form with the control, so its source no longer needs the placeholder.

A release configuration that makes a production ACCDE and links tables with the production profile:

<PropertyGroup Condition="'$(Configuration)' == 'Release'">
  <Accde>true</Accde>
  <AppMode>Production</AppMode>
  <ConnectionProfile>PROD</ConnectionProfile>
</PropertyGroup>

wkl-office build Customers.acproj -c Release

• Project folder – which file goes where and what is versioned
• Build configurations and delivery profiles – what a configuration and a profile decide
• Command-line reference
• Source layout and formats
• How to: Keep sources in folders of your own