Access-Anwendung aus ihren Textquellen bauen

Verwalten Sie eine Access-Anwendung mit WKL-Steuerelementen als Text in der Versionsverwaltung, und bauen Sie ACCDB und ACCDE daraus mit einem einzigen Befehl. So erzeugt jeder Entwickler und jeder Build-Rechner dieselbe Anwendung.

Neue Projekte: Das WKL Office SDK baut, exportiert und prüft Access-Anwendungen aus Quellen mit mehr Schritten als dieses Build-Werkzeug (Status und Abgleich mit dem geöffneten Access, Rundlaufprüfung, MSBuild, ein Access-Add-In) und übernimmt access-app.json mit wkl-office migrate access-app.json -o <folder> (Dokumentation des WKL Office SDK, „Projekt des Build-Werkzeugs der WKL Forms Object Library migrieren“). Für bestehende Projekte funktioniert dieses Build-Werkzeug weiterhin.

Voraussetzungen: WKL Forms Object Library 1.38 oder höher (das Build-Werkzeug wird mit dem Release ausgeliefert); das Hausdesign Riviera im Paket ab 1.44; -Normalize und finish ab 1.45.1.

Lösungsüberblick

Das Repository ist die Quelle. Module und Klassenmodule so, wie der VBA-Editor sie exportiert; Formulare, Berichte, Abfragen und Makros so, wie SaveAsText sie schreibt; Tabellen als SQL; ein Office-Design und Menübänder als Dateien. ACCDB und ACCDE sind Build-Ergebnisse und werden nicht aufbewahrt.
Eine Projektdatei access-app.json nennt die Anwendung, ihre Verweise und ihre Quellordner (Referenz).
Ein Befehl baut: tools\build\Build-AccessApp.ps1 -Project access-app.json. Er führt Access verborgen aus, in der Reihenfolge, die Access braucht (das Design vor den Formularen), und bricht mit dem fehlgeschlagenen Schritt ab.
WKL-Steuerelemente in Formularen kommen mit dem Text des Formulars, wenn das Formular in Access bearbeitet und mit SaveAsText gespeichert wurde. Ein Formular, das ein Skript anlegt, erhält dort, wo das Steuerelement hingehört, ein Rechteck mit Marke (Tag) wkl:<Kind>; der Build ersetzt es durch den freigegebenen Steuerelementbaustein dieser Art.

Umsetzung

Ein Repository mit diesem Aufbau:

my-app/
├─ access-app.json
└─ src/
   ├─ tables/01-customer.sql
   ├─ modules/basApp.bas, clsCustomer.cls
   ├─ forms/frmShell.form.txt, frmKunden.form.txt
   ├─ ribbons/AppRibbon.xml
   └─ theme/          (die Teile eines .thmx-Pakets: [Content_Types].xml, theme/theme/theme1.xml ...)

Die Projektdatei:

{
  "name": "Kunden",
  "references": [ { "library": "WklForms", "major": 2, "minor": 0 } ],
  "tables": "src/tables",
  "modules": "src/modules",
  "theme": { "folder": "src/theme", "name": "Riviera" },
  "ribbons": "src/ribbons",
  "forms": "src/forms",
  "properties": { "AppTitle": "Kunden", "StartUpForm": "frmShell", "CustomRibbonID": "AppRibbon" }
}

Bauen Sie sie (aus einer beliebigen PowerShell; das Skript startet sich selbst in der Bitversion von Office neu):

& '<release>\tools\build\Build-AccessApp.ps1' -Project .\my-app\access-app.json

Danach enthält der Ausgabeordner my-app\out die Dateien Kunden.accdb und Kunden.accde.

Das Hausdesign „Riviera“ wird mit dem Release-Paket unter themes\riviera ausgeliefert. Um es statt einer Kopie in Ihrem Projekt zu verwenden, lassen Sie das Design auf das Paket zeigen (<package> steht für den Ordner des Release-Pakets):

"theme": { "folder": "<package>/themes/riviera", "name": "Riviera" }

Wenn Sie ein eigenes Design erstellen, darf theme1.xml vor seinem Wurzelelement keine Kommentare enthalten: Access verwirft ein solches Design ohne Meldung.

Um in Access vorgenommene Änderungen zurück ins Repository zu bringen, exportieren Sie die Entwicklungsdatenbank in die Quellordner derselben Projektdatei. Export-AccessApp.ps1 liegt neben dem Build-Skript (<project> steht für den Ordner Ihres Projekts):

.\tools\build\Export-AccessApp.ps1 -Project <project>\access-app.json -Database <project>\dev\Kunden.accdb
.\tools\build\Export-AccessApp.ps1 -Project <project>\access-app.json -Only frmKunden,basApp

Das Skript schreibt Module so, wie der VBA-Editor sie exportiert, Formulare, Berichte, Abfragen und Makros so, wie SaveAsText sie schreibt (ohne die Zeile Checksum, die sich bei jedem Speichern ändert), und die Menübänder aus USysRibbons. Tabellen, das Design und die Datenbankeigenschaften werden nicht zurückgeschrieben: Sie sind in den Quellen definiert. Objekte, die nur in einem Ordner vorhanden sind, werden aufgelistet, nicht gelöscht. Schließen Sie die Datenbank vorher in Ihrem eigenen Access; das Skript öffnet sie in einer eigenen, verborgenen Access-Instanz. Mit -Normalize lässt es in Formular- und Berichtstexten die Zeilen weg, die Access bei jedem Speichern neu schreibt, auch ohne Änderung – die Blöcke GUID, NameMap und RecSrcDt sowie NoSaveCTIWhenDisabled. Ein Diff zeigt dann nur echte Änderungen; der Build erzeugt diese Werte wieder.

Schritte, die das Werkzeug nicht kennt – Gruppen des Navigationsbereichs, ausgeblendete Objekte –, gehören in eine eigene Funktion, die der Build nach den Eigenschaften ausführt und die Sie in der Projektdatei nennen:

"finish": "FinishBuild"

Public Function FinishBuild() As String
    On Error GoTo Failed
    CurrentDb.Properties("StartUpShowDBWindow") = False   ' any step the tool does not know
    FinishBuild = "OK"
    Exit Function
Failed:
    FinishBuild = "Fehler " & Err.Number & ": " & Err.Description
End Function

Jeder andere Text als "" oder "OK" bricht den Build mit diesem Text ab.

Hinweise

Zum Bauen ist Access erforderlich. Der Build verwendet LoadFromText und SysCmd 603 von Access selbst; mit der Access Runtime lässt sich nicht bauen. Auf dem Rechner muss das WKL-Release in der Bitversion von Office registriert sein, wie auf einem Entwicklungsrechner (Freigegebenes Paket installieren).
Der ACCDE-Schritt wiederholt sich. Access kehrt beim Erstellen der ACCDE gelegentlich ohne Datei und ohne Fehler zurück; das Skript versucht es bis zu dreimal und prüft die Datei.
Keine Dialogfelder. Access läuft verborgen. Ein Modul, das sich nicht kompilieren lässt, bricht den Build mit dem Schritt und dem Hinweis ab, im VBA-Editor zu kompilieren. Beendet wird nur die Access-Instanz, die das Skript gestartet hat.
Vertrauenswürdiger Speicherort nur während des Builds. Der Ausgabeordner ist während des Builds ein vertrauenswürdiger Speicherort für den aktuellen Benutzer und wird danach wieder entfernt. Um die gebaute Anwendung von dort zu öffnen, vertrauen Sie dem Ordner selbst: <release>\tools\deploy\Set-AccessTrustedLocation.ps1 -Path <output folder> (pro Benutzer, keine Administratorrechte). Ohne diesen Schritt öffnet Access die Datenbank mit deaktivierten aktiven Inhalten: kein VBA, kein Code des Startformulars, und die WKL-Steuerelemente werden nicht geladen.
Ohne Normalisierung ändern Exporte einige Zeilen. Access schreibt bei jedem Speichern neue Werte in den Text eines Formulars, auch wenn sich das Formular nicht geändert hat (GUIDs in Binärblöcken, NameMap, RecSrcDt, NoSaveCTIWhenDisabled); exportieren Sie mit -Normalize, damit diese Werte nicht ins Repository gelangen.
Bilder behalten den Pfad des Rechners, auf dem sie eingefügt wurden. Die Eigenschaft Picture eines aus einer Datei eingefügten Bildsteuerelements enthält beim ersten Export den absoluten Pfad dieser Datei, nur als Information (das eingebettete Bild steht im Formulartext). Ein Build aus dem Text behält nur den Dateinamen; der nächste Export zeigt diese Zeile deshalb einmal als geändert.
Beim Öffnen der gebauten Datenbank läuft das Startformular. StartUpForm wirkt beim Öffnen einer Datenbank. Ein Skript, das die gebaute Datenbank danach für eigene Schritte öffnet, startet die Anwendung, und ein geöffnetes Formular lässt sich weder ausblenden noch im Entwurf ändern (Fehler 2564). Legen Sie solche Schritte in die Funktion finish, die läuft, bevor die Datenbank erneut geöffnet wird, oder setzen Sie StartUpForm in Ihrem eigenen Skript als Letztes.
Nicht abgedeckt sind verknüpfte Tabellen (verwenden Sie beim Start WklLinkManager.EnsureLinks), Daten lokaler Tabellen über INSERT-Anweisungen hinaus und Beziehungen.

Access-Anwendung aus ihren Textquellen bauen

Lösungsüberblick

Umsetzung

Hinweise

Verwandte Themen