Referenz der Projektdatei: .acproj

<Project>
  <PropertyGroup>
    <SchemaVersion>2</SchemaVersion>
    <AssemblyName>Kunden</AssemblyName>
    <SourceRoot>source</SourceRoot>
    <BaseOutputPath>build</BaseOutputPath>
    <DeliveryRoot>delivery</DeliveryRoot>
    <Configurations>Kunde</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="tblLaender" Policy="SeedData" />
    <TablePolicy Include="tblCache" Policy="Ignore" />
  </ItemGroup>
</Project>

Die Projektdatei benennt eine Access-Anwendung, den Ort ihrer Quellen und die Art, wie jede Build-Konfiguration sie baut. Sie ist MSBuild-XML; dotnet build liest also dieselbe Datei, und jedes Werkzeug des SDK liest sie auf dieselbe Weise.

Eine PropertyGroup mit Condition="'$(Configuration)' == '<name>'" überschreibt Accde, AppMode und ConnectionProfile für diese Konfiguration; die übrigen Eigenschaften gelten für alle Konfigurationen gleich (siehe Hinweise).

Ohne weitere Angabe liegen die Quellen an festen Orten unterhalb von SourceRoot (Quellstruktur und Formate). Quellelemente legen eine Art von Quellen an einen anderen Ort: Jedes Element erfasst die Dateien, die sein Attribut Include nennt, relativ zum Ordner der Projektdatei.

<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>

Regeln:

• Include und Exclude nennen Dateien oder Muster, mehrere durch ; getrennt, mit den Platzhalterzeichen von MSBuild: ? steht für ein Zeichen, * für beliebig viele Zeichen innerhalb eines Datei- oder Ordnernamens, ** für beliebig viele Ordner. Groß- und Kleinschreibung spielt keine Rolle. Der Basisordner eines Musters ist der Ordner vor dem ersten Platzhalterzeichen, bei ui\pages\*.form.txt also ui\pages.
• Ein Element erfasst nur Dateien mit der Dateinamenerweiterung seiner Art: Unter AccessForm erfasst ui\pages\* die .form.txt-Dateien dort, nicht die Seiteneinstellungen eines Berichts daneben.
• Eine Art ohne Elemente bleibt an ihrem Standardort. Ein Projekt ohne Quellelemente wird genau wie bisher gelesen.
• Nennt ein Element eine Datei ausdrücklich und erfasst sie auch ein Muster eines anderen Elements, gehört die Datei zu dem Element, das sie nennt. Erfassen zwei Muster dieselbe Datei, ist das ein Fehler: Nennen Sie die Datei ausdrücklich in einem Element, oder grenzen Sie die Muster ein.
• check und jeder Befehl, der die Quellen liest, melden als Fehler:
  • ein Element, das keine Datei erfasst;
  • eine Datei mit der Erweiterung eines Objekts, einer Tabelle oder von Tabellendaten, die kein Element erfasst, unterhalb von SourceRoot oder unterhalb des Basisordners eines Musters (eine bewusst ausgelassene Datei schließen Sie mit Exclude aus);
  • zwei Dateien mit demselben Objekt.
• Die Ordner build, obj, .git und .vs im Projektordner und der Ordner von BaseOutputPath werden nie durchsucht.
• Der Export schreibt jedes Objekt in die Datei zurück, aus der es stammt. Ein neues Objekt kommt nach AccessDefaultFolder<Kind>; ist das nicht gesetzt, in den Basisordner des ersten Elements seiner Art, sonst an seinen Standardort.
• Pfade in Meldungen (check, roundtrip) sind relativ zum Ordner der Projektdatei.

• Was nicht in der Datei steht. Verweise (in Prioritätsreihenfolge) und Datenbankeigenschaften (typisiert) sind eigene Quellen, source/references.json und source/application/properties.json; ein Export schreibt also nie die Datei neu, die ein Mensch bearbeitet.
• Andere Elemente bleiben MSBuild überlassen: Das SDK liest nur die oben genannten Eigenschaften und Elemente; die Datei darf also eigene Eigenschaften und den Import der MSBuild-Targets enthalten.
• Bedingungen. Eine Eigenschaftsgruppe mit SDK-Eigenschaften akzeptiert nur die Form '$(Configuration)' == '<name>'; eine andere Bedingung wird abgelehnt. In einer Konfigurationsgruppe übernimmt das SDK Accde, AppMode und ConnectionProfile; eine andere SDK-Eigenschaft dort (SchemaVersion, AssemblyName, SourceRoot, BaseOutputPath, DeliveryRoot, Configurations, TargetAccess, Template, Finish, Test, ControlBlocks, NeutralLanguage, AccessDefaultFolder<Kind>) wird abgelehnt, und eigene Eigenschaften bleiben MSBuild überlassen. Elementgruppen mit SDK-Elementen akzeptieren keine Bedingung.

Das Anwendungsmodell der WKL Forms Object Library (application/app-model.json) verlangt für jeden Modus andere Starteigenschaften: Entwicklung (eine ACCDB), Administration (eine ACCDE im vollständigen Access) und Produktion (eine ACCDE in der Runtime) – in der Produktion zum Beispiel keine Umgehungstaste und keine Access-Spezialtasten. Die Anwendung korrigiert sie selbst, wenn sie bei ihrem Start EnsureApplication aufruft. Mit AppMode schreibt der Build sie sofort in die ACCDE, sodass die ausgelieferte Datei ab dem ersten Öffnen stimmt, noch bevor Code läuft. AppIcon wird aus der ACCDE entfernt, weil es eine Datei des Build-Rechners benennt; die Anwendung schreibt beim ersten Start das Symbol des Benutzerrechners. Die ACCDB bleibt eine Entwicklungsdatenbank. check lehnt einen unbekannten Modus ab und warnt, wenn die Quellen kein Anwendungsmodell enthalten oder die Konfiguration keine ACCDE erzeugt.

Objekte, Tabellen (mit ihren Richtlinien), Beziehungen, Verweise und Eigenschaften der Vorlage kommen zu denen der Anwendung hinzu. Eine Quelle der Anwendung ersetzt die gleichnamige der Vorlage; die Verweise der Anwendung stehen zuerst; eine Eigenschaft der Anwendung hat Vorrang. Design, Modelle und die Abschlussfunktion stammen aus der Vorlage, wenn die Anwendung keine eigenen hat. Eine Vorlage, die selbst eine Vorlage nennt, wird abgelehnt. export schreibt nichts, was allein die Vorlage beiträgt; um ein Objekt der Vorlage für eine Anwendung zu ändern, kopieren Sie seine Datei in die Quellen der Anwendung.

Eine Vorlage, auf der mehrere Anwendungen aufbauen, gehört nicht in das Repository der Anwendung: Setzen Sie <Template> auf den Ordnernamen der Vorlage und die Umgebungsvariable WKL_ACCESS_TEMPLATES auf den Ordner, der sie enthält (mehrere Ordner durch ; getrennt). Eine neue Fassung der Vorlage kommt dann mit dem nächsten Bau an.

Der Build führt sie mit Application.Run nach den Modellen aus, vor der letzten Kompilierung und der ACCDE, für Schritte, die das SDK nicht kennt (zum Beispiel das Füllen von Generated-Tabellen). Sie gibt bei Erfolg "" oder "OK" zurück; jeder andere Text bricht den Build mit diesem Text ab. Ein Fehler, den sie nicht behandelt, öffnet den Laufzeitfehlerdialog von VBA, den der Build abbricht und meldet. Sie darf höchstens 5 Minuten laufen; danach wird das verborgene Access des Builds beendet, und der Build schlägt fehl. Sie sollte dem VBA-Fehlergerüst einer Automatisierungshilfe folgen: ihre Fehler behandeln und einen Text zurückgeben, statt einen Fehler auszulösen. check lehnt einen Namen ab, der keine öffentliche Funktion eines Standardmoduls ist.

wkl-office test ruft sie mit Application.Run im verborgenen Access des Laufs auf. Sie gibt die Namen der Testprozeduren zurück – öffentliche Prozeduren (Sub oder Function) von Standardmodulen ohne Argumente –, als Array (Array("Orders_Create", "Orders_Delete")) oder als einen Text mit durch Kommas getrennten Namen. Ein Projekt, das eine Testfunktion nennt, erhält bei jedem Build das Testmodul WklTest des SDK, auch wenn seine Quellen keines enthalten; ein Modul WklTest in den Quellen wird immer durch das des SDK ersetzt, und der nächste Export schreibt das des SDK in die Quellen. check lehnt einen Namen ab, der keine öffentliche Funktion eines Standardmoduls ist. Siehe Eine Anwendung testen.

Ein Rechteck in einem Formular, dessen Tag wkl:<Kind> lautet (wkl:Grid, wkl:ActionBar …), wird beim Laden des Formulars durch den Steuerelementbaustein <Kind>.control.txt ersetzt, mit Name, Position, Größe und Verankerung des Rechtecks. Das Release-Paket der WKL Forms Object Library liefert die Bausteine in control-blocks mit. check nennt jeden Platzhalter, dessen Baustein fehlt. Der Export schreibt das Formular mit dem Steuerelement; seine Quelle benötigt den Platzhalter also nicht mehr.

Eine Release-Konfiguration, die eine ACCDE für die Produktion erzeugt und Tabellen mit dem Produktionsprofil verknüpft:

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

wkl-office build Kunden.acproj -c Release

• Projektordner – welche Datei wo liegt und was versioniert wird
• Build-Konfiguration und Auslieferungsprofil – was eine Konfiguration und ein Profil festlegen
• Befehlszeilenreferenz
• Quellstruktur und Formate
• Quellen in eigenen Ordnern ablegen