app-manifest.json

Die Beschreibung eines ausgelieferten Ziels einer Access-Anwendung, die tools/build/Build-AccessApp.ps1 neben die ausgelieferte Datei schreibt, wenn die Projektdatei einen Eintrag deploy hat (access-app.json). Sie teilt dem Programm, das die Anwendung auf dem Computer eines Benutzers ablegt, mit, was die Datei ist, welche Version sie hat und was sie braucht.

Signatur

{
  "format": 1,
  "product": "Kunden",
  "version": "1.4.0",
  "target": "Production",
  "file": "Kunden.accde",
  "sha256": "3f5a...e09c",
  "size": 1835008,
  "bitness": "x86",
  "runtime": true,
  "requires": [ { "library": "WklForms", "version": "2.0" } ],
  "built": "2026-10-12T09:30:00Z"
}

Zusammenfassung

Eine Datei je Zielordner, UTF-8 ohne Bytereihenfolgemarke. Ein Programm liest sie, um die ausgelieferte Datei zu prüfen (sha256, size) und um zu entscheiden, ob der Computer sie ausführen kann (bitness, runtime, requires).

Parameter

Eintrag	Typ	Beschreibung
`format`	Zahl	Version des Schemas dieses Manifests: `1`. Ein Leser lehnt eine höhere Zahl ab, die er nicht kennt. Sie hat nichts mit den Formaten 1 und 2 der `bootstrapper.json` des Starters zu tun (Wkl.Bootstrapper): Ein Manifest mit Schema 1 wird von Projekten beider Formate gelesen.
`product`	Text	`name` der Projektdatei.
`version`	Text	`deploy.version` der Projektdatei.
`target`	Text	`Development`, `Administration` oder `Production`.
`file`	Text	Dateiname der ausgelieferten Datenbank im selben Ordner.
`sha256`	Text	SHA-256 (FIPS 180-4) der Datei, hexadezimal in Kleinbuchstaben.
`size`	Zahl	Größe der Datei in Byte.
`bitness`	Text	`x86` oder `x64` für eine ACCDE – sie läuft nur in Access der Bitversion, mit der sie gebaut wurde –, `any` für eine ACCDB.
`runtime`	Ja/Nein	`true` für die Produktion: Die Datei ist für die Access Runtime bestimmt. Die Verwaltung braucht das vollständige Access; die Entwicklung ist eine ACCDB für Entwickler.
`requires`	Liste	Die Typbibliotheken aus den `references` des Projekts, die eine `library` nennen (`WklForms`, `WklJSON`), jeweils mit der Version, gegen die die Anwendung gebaut wurde: der Version, die Access in der Datenbank aufgezeichnet hat, also der höchsten, die auf dem Build-Rechner registriert ist (der Build warnt, wenn sie über der Version in `references` liegt). Manifeste von Anwendungen, die gegen ein Release 1.x gebaut wurden, nennen die Bibliothek `WklComponents`, wie sie bis 1.68 hieß.
`built`	Text	Zeitpunkt des Builds, UTC (ISO 8601).

Hinweise

sha256 und size beschreiben die Datei im gebauten Zustand, vor dem ersten Öffnen. Access schreibt in eine ACCDE oder ACCDB, wenn es sie öffnet, auch mit /runtime; Größe und Prüfsumme ändern sich dadurch. Eine Datei im Ausgabeordner, die einmal geöffnet wurde, stimmt nicht mehr mit ihrem Manifest überein. Testen Sie eine Auslieferung an einer Kopie: Kopieren Sie die Datei, vergleichen Sie Größe und Prüfsumme mit dem Manifest und öffnen Sie dann die Kopie.
Ein schreibgeschützter Ort lässt die Datei unverändert. Das Schreiben beim Öffnen ist nicht zwingend: In einem Ordner, in dem der Benutzer nur lesen darf (zum Beispiel unter Program Files oder auf einer Freigabe mit reinem Lesezugriff), öffnet Access die ACCDE, ohne sie zu beschreiben, ohne Sperrdatei (.laccdb) und ohne Fehler oder Meldung, auch mit /runtime, und zwei Access-Instanzen können sie gleichzeitig geöffnet haben; Größe und Prüfsumme bleiben unverändert. Eine Anwendung, die Dateien neben sich schreibt (ein Protokoll, einen Bericht), kann das dort nicht; solche Dateien gehören in einen Ordner des Benutzers.
Was die Datei des Ziels bereits enthält: die Starteigenschaften ihrer Betriebsart aus dem Anwendungsmodell (Navigationsbereich, Menüs, Sondertasten, Umgehungstaste, Statusleiste, Titel, Startformular, Menüband). Sie wirken beim ersten Öffnen auf dem Computer des Benutzers.
Version der WKL-Bibliotheken: Eine Datenbank läuft mit dem registrierten Release ihrer Version oder einem neueren; mit einem älteren wird sie nicht unterstützt und kann mit Fehler 459 abbrechen (Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen).
built ändert sich mit jedem Build; vergleichen Sie Dateien über sha256, nicht das Manifest als Ganzes.
Die Prüfsumme erkennt eine beschädigte Kopie, keine absichtliche Änderung: sha256 steht in derselben unsignierten Datei; wer die Datei ersetzen kann, kann auch das Manifest ersetzen.

Codebeispiel

Eine ausgelieferte Datei vor dem Ablegen in PowerShell prüfen:

$manifest = Get-Content .\production\app-manifest.json -Raw | ConvertFrom-Json
$hash = (Get-FileHash (Join-Path .\production $manifest.file) -Algorithm SHA256).Hash.ToLowerInvariant()
if ($hash -ne $manifest.sha256) { throw "$($manifest.file) ist beschaedigt." }

Vererbung

Keine