Was der Starter schreibt und meldet

Diese Seite beschreibt den Weg von 1.0: Dateien im Format 1, deren Komponenten keine registration.json mitbringen. Den Installer von 2.0 (Format 2 oder Komponenten mit registration.json), der deregistriert und entfernt, was er installiert hat, beschreibt Der Installer.

Was Wkl.Bootstrapper.exe auf einem PC hinterlässt, wie ein Aufruf endet und was /diagnose meldet. Nutzen Sie die Seite, um eine Ablage nachträglich zu prüfen, um eine Anwendung zu entfernen (siehe Anwendung von einem PC entfernen) und um Skripte oder Tickets auf die Diagnose zu stützen.

Wie ein Aufruf endet

Der Starter wartet nicht auf Access. Er prüft den PC, registriert bei Bedarf die Komponenten, setzt den vertrauenswürdigen Speicherort, legt die Version ab, startet MSACCESS.EXE und beobachtet den neuen Prozess zwei Sekunden lang. Dann endet er:

Exitcode	Bedeutung
`0`	Access wurde mit der Kopie des Benutzers gestartet und lief zwei Sekunden später noch. Das bedeutet nicht, dass die Anwendung ihr erstes Formular geöffnet hat: Ein Fehler im eigenen Startcode der Anwendung zeigt sich in Access, nachdem der Starter beendet ist.
`60`	Access konnte nicht gestartet werden oder endete innerhalb der zwei Sekunden (eine abgelehnte Datei, ein fehlender Verweis, eine Richtlinie).
jeder andere	Das erste fehlende Teil, mit seinem Code; siehe Fehlercodes des Starters. Es wurde nichts gestartet.

Der Exitcode ist dieselbe Zahl, die das Fehlerfenster zeigt, und die erste Zahl von /diagnose. Mit Fenster (ohne Schalter) kehrt der Starter zurück, nachdem die Person das Fehlerfenster geschlossen hat; mit /quiet zeigt er nichts an und kehrt sofort zurück. Während das läuft, erscheint das Startfenster als Begrüßungsbildschirm (start.splash.duration; mit 0 erscheint ein Fortschrittsfenster nur, wenn Ablegen oder Registrieren länger als 0,8 Sekunden dauert).

Versionen

Der Starter legt immer die Version ab und startet sie, die app-manifest.json in der Quelle nennt. Ohne deliveryKey vergleicht er diese Version nie mit den Kopien im Profil: Eine Quelle mit einer niedrigeren Version als zuvor wird ebenfalls abgelegt und gestartet – so kehrt eine Auslieferung zu einer früheren Version zurück. Mit deliveryKey (ab 2.2.4) wird eine niedrigere Version als je installiert nur abgelegt, wenn die signierte Auslieferung die höhere zurückzieht; sonst startet die installierte Version (Code 52, siehe Signierte Auslieferungen).

Regel
Form von `version`	Zwei bis vier durch Punkte getrennte Zahlen, jede mit ein bis fünf Ziffern: `1.4`, `1.4.0`, `0.1.123.4`. Buchstaben, ein Zusatz wie `0.1.0-demo` sowie vor- oder nachgestellter Text werden mit Code 11 abgelehnt (Die Einstellungen der Anwendung können nicht gelesen werden); `deploy.version` des Build-Werkzeugs wird zu diesem Wert.
Reihenfolge	Numerisch, Teil für Teil: `0.1.10` ist neuer als `0.1.9`. Verwenden Sie in jeder Version dieselbe Anzahl von Teilen: `1.4` und `1.4.0` sind verschiedene Versionen, und `1.4` gilt als die ältere.
Aufbewahrte Versionen	Die neuesten `keepVersions` nach dieser Reihenfolge und immer die Version, die gerade gestartet wird, sowie `lastWorkingVersion` – die Version, die zuletzt gestartet wurde (nicht die höchste), verzeichnet in `State\provisioning.json` nach jedem erfolgreichen Start. Ein Ordner, dessen Kopie in Access geöffnet ist (ihre `.laccdb` existiert), wird nie entfernt.
Gleiche Version, andere Datei	Ein neuer SHA-256 für eine bereits abgelegte Version gilt als neue Auslieferung: Die Kopie wird im selben Ordner `Frontends\<version>` erneut abgelegt, und was die Kopie des Benutzers enthielt, wird ersetzt. Solange diese Kopie in Access geöffnet ist, lässt sich der alte Ordner nicht beiseiteschieben: Der Start endet mit Code 41 (Die Anwendung konnte nicht in das Benutzerprofil kopiert werden), die geöffnete Kopie bleibt unberührt, und der nächste Start, nachdem Access geschlossen wurde, legt die neue Datei ab (Windows verweigert das Verschieben eines Ordners, der eine geöffnete Datei enthält). Geben Sie jedem Build eine eigene Version, um das zu vermeiden.

Ordner im Benutzerprofil

Alles zu einer Anwendung liegt unterhalb von %LOCALAPPDATA%\WKL\<product>, wobei <product> der Wert von product in bootstrapper.json ist:

Ordner	Inhalt
`Frontends\<version>\`	Die Kopie des Benutzers für jede Version, mit der INI-Datei von `ini`, wenn eine gesetzt ist. Die neuesten `keepVersions` Versionen bleiben, immer die laufende und die zuletzt gestartete; eine verwendete Version wird nie entfernt.
`State\provisioning.json`	Was abgelegt wurde: `version`, `file`, `sha256` und `size` der Auslieferung, gegen die die Kopie geprüft wurde, `writeTicks`, `lastWorkingVersion`.
`Logs\bootstrapper.log`	Das Protokoll (siehe unten).

Die WKL-Komponenten, die die Anwendung ausliefert, werden einmal je Release und Bitbreite nach %LOCALAPPDATA%\WKL\Components\<release>\<x86|x64>\ kopiert und von dort registriert. Diesen Ordner teilen sich alle Anwendungen des Benutzers, die Komponenten ausliefern.

Das Protokoll

%LOCALAPPDATA%\WKL\<product>\Logs\bootstrapper.log, UTF-8, eine Zeile je Schritt: Uhrzeit, Prozess-ID, Schritt, Text. Bei 1 MB wird es nach bootstrapper.1.log verschoben (fünf ältere Dateien bleiben erhalten). Es enthält nie INI-Werte, Kennwörter oder Verbindungszeichenfolgen. /diagnose schreibt kein Protokoll.

Schritt	Text
`start`	Produkt und Version des Bootstrappers
`manifest`	Produkt, Version, Datei, Ziel, Bitbreite und `runtime` aus `app-manifest.json`
`environment`	Access, WKL-Registrierung, .NET Desktop Runtime
`components`	der registrierte DLL-Pfad (nur wenn die Anwendung WKL-Komponenten braucht)
`trust`	der vertrauenswürdige Ordner
`placement`	Nur auf dem Weg von 1.0: `placed <path>`, wenn die Kopie jetzt abgelegt wurde, `in place <path>`, wenn eine frühere Kopie übernommen wurde
`install`	Installer von 2.0: `install <version> <copy> components <release>` je installierter Version (siehe Wann 2.0 installiert und wann 1.0 läuft)
`end`	Code, Name und Detail des Ergebnisses
`settings`	Aktionen des Einstellungsfensters: Komponenten einrichten, eine Version verwerfen oder starten, aufräumen

Eine Installation nachweisen (Installer von 2.0). Welche Auslieferungen der Installer von 2.0 übernimmt, steht unter Wann 2.0 installiert und wann 1.0 läuft; für sie ist der Nachweis die Protokollzeile install <version> <copy> ... zusammen mit /list /json (die installierten Versionen und ihre Komponenten aus der Installer-Datenbank). State\provisioning.json wird nicht geschrieben, und die Zeile placement erscheint nicht. Ein Test, der eine Installation von Hand entfernt, lässt ihren Eintrag unter „Apps“ und ihren Nachweis in der Installer-Datenbank zurück; entfernen Sie sie stattdessen mit /uninstall /quiet.

Eine Ablage nachweisen (Weg von 1.0). Die Kopie wird geprüft, bevor sie abgelegt wird: Der Starter kopiert die Auslieferung in einen temporären Ordner, vergleicht ihre Größe und ihren SHA-256 mit app-manifest.json und benennt den Ordner erst dann in Frontends\<version> um. Eine Zeile placed <path> bedeutet daher, dass die Kopie in diesem Moment dem Manifest entsprach; eine Abweichung endet mit Code 42 und hinterlässt keine Ablage. State\provisioning.json verzeichnet sha256 und size des Manifests für diese Ablage. Größe und SHA-256 der Kopie selbst werden nicht protokolliert: Access ändert die Datei, wenn es sie öffnet (auch eine mit /runtime geöffnete ACCDE), sodass sie nach dem ersten Start ohnehin nicht mehr zum Manifest passen würden.

Der vertrauenswürdige Speicherort

Der Starter macht Frontends zu einem vertrauenswürdigen Speicherort von Access für den Benutzer, mit Unterordnern, damit sich die Kopien ohne Sicherheitswarnung öffnen:


Schlüssel	`HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\Security\Trusted Locations\WKL.<product>`
`Path`	`%LOCALAPPDATA%\WKL\<product>\Frontends\` (erweitert, mit abschließendem umgekehrtem Schrägstrich)
`AllowSubfolders`	`1` (DWORD)
`Description`	`WKL <product>: Anwendung des Benutzers (Wkl.Bootstrapper)`

Er wird bei jedem Start geprüft und nur geschrieben, wenn Path oder AllowSubfolders abweichen. Der Starter entfernt ihn nie. Eine Gruppenrichtlinie, die vertrauenswürdige Speicherorte abschaltet oder nur die der Richtlinie zulässt, beendet den Start mit Code 50.

Die Registrierung der Komponenten

Liefert die Anwendung WKL-Komponenten aus (components in bootstrapper.json) und fehlt die Registrierung des Benutzers oder ist sie älter, als die Anwendung braucht, führt der Starter regsvr32 /s /n /i:user in der Bitbreite von Access für die Kopie in %LOCALAPPDATA%\WKL\Components\... aus. Das schreibt unter HKEY_CURRENT_USER\Software\Classes dieselben Schlüssel wie die eigene Registrierung des Release-Pakets. Eine ausreichend neue Registrierung bleibt unangetastet. Der Starter deregistriert nie. Auch eine Registrierung einer anderen Hauptversion derselben Typbibliothek, die eine andere Anwendung noch benötigt, wird nicht ersetzt; der Start hält mit Code 37 an. Registriert wird die DLL, die in der registration.json des Ordners components steht (Pakete vor Release 1.57 der WKL Forms Object Library haben keine solche Datei; dort ist es Wkl.Access.Components.dll). Ab WKL Bootstrapper 3.2 erkennt der Starter die vorhandene Registrierung an der LIBID der Typbibliothek und an ihrer Version (HKEY_CURRENT_USER\Software\Classes\TypeLib\{LIBID}), nicht an Dateinamen oder ProgIDs: Ein neues Release einer Bibliothek, auch eines mit umbenannten Dateien, braucht deshalb keinen neuen Starter. WKL Office JSON, auf das manche Anwendungen ebenfalls verweisen, liefert der Starter mit einer Projektdatei im Format 1 nicht aus und prüft es auch nicht; eine Projektdatei im Format 2 registriert es mit einem Eintrag registerCom. Welche Schlüssel die Registrierung schreibt und entfernt, beschreibt die Dokumentation der WKL Forms Object Library (Was die Registrierung pro Benutzer schreibt).

/diagnose und /diagnose /json

/diagnose führt jede Prüfung eines Starts aus, ohne etwas zu ändern (keine Registrierung, kein vertrauenswürdiger Speicherort, keine Kopie, kein Protokoll), und gibt das Ergebnis aus; /json gibt es als ein JSON-Objekt aus. Der Exitcode ist code.

Feld	Typ	Inhalt
`code`	Zahl	Das Ergebnis: `0`, wenn ein Start gelingen würde, sonst der Fehlercode.
`name`	Zeichenfolge	Der Name des Ergebnisses, zum Beispiel `Ok`, `OdbcDriverMissing`.
`detail`	Zeichenfolge	Technisches Detail; bei `0` „`<product> <version> can start.`“
`bootstrapper`	Zeichenfolge	Version und Build des Starters, zum Beispiel `1.0.1+2f46abe...`.
`product`	Zeichenfolge	`product` aus `bootstrapper.json`.
`version`	Zeichenfolge	Version in der `app-manifest.json` der Quelle.
`file`	Zeichenfolge	`<file>, <target>, <bitness>` des Manifests.
`source`	Zeichenfolge	Der Quellordner als vollständiger Pfad.
`placed`	Zeichenfolge	Versionsordner im Benutzerprofil, durch Kommas getrennt; `nothing yet`, wenn keiner existiert.
`windows`	Zeichenfolge	Bitbreite von Windows.
`access`	Zeichenfolge	Edition, Bitbreite, Version und Pfad von Access und wie es gefunden wurde; `not found`.
`components`	Zeichenfolge	Registriertes WKL-Release (Version der Typbibliothek), für den Benutzer oder den Computer, und der DLL-Pfad; `not registered`.
`desktopRuntime`	Zeichenfolge	Höchste .NET 10 Desktop Runtime in der Bitbreite von Access oder `no .NET 10 Desktop Runtime`.
`odbcDrivers`	Array von Zeichenfolgen	`<name>: installed` oder `<name>: missing` je Eintrag von `odbcDrivers`.
`odbcDataSources`	Array von Zeichenfolgen	Ab 1.0.1: `<name>: present` oder `<name>: missing or other bitness` je Eintrag von `odbcDataSources`.
`paths`	Array von Zeichenfolgen	Die Ordner `Frontends` und `Logs` des Produkts.
`plan`	Array von Zeichenfolgen	Ab 2.0, für eine Projektdatei im Format 2, die starten kann: was ein Start wohin installieren würde – der Versionsordner, jeder Eintrag mit seinen Dateien (`<source> -> <target>`, eingerückt), Schlüssel der Registrierungsdatenbank, die INI-Datei, Verknüpfungen und das Startziel. Sonst leer.

/whatif <file> stellt dieselbe Diagnose für eine beliebige Projektdatei (relative Pfade werden gegen den Ordner dieser Datei aufgelöst), sodass sich ein Projekt ausprobieren lässt, bevor es ausgeliefert wird; mit /json wird jedes Zeichen außerhalb von ASCII maskiert (\uXXXX), sodass die Ausgabe in jeder Codepage gleich lesbar ist.

Die Diagnose hält bei der ersten fehlschlagenden Prüfung an, daher können die Felder danach leer sein: Bei Code 10 oder 11 sind nur code, name, detail, bootstrapper und windows gefüllt. Felder kommen nur hinzu; ein Skript sollte Felder ignorieren, die es nicht kennt.

Mehrere Starter gleichzeitig

Starter mit verschiedenen Werten für product sind unabhängig: Jeder hat eigene Ordner, ein eigenes Protokoll, einen eigenen Zustand und einen eigenen vertrauenswürdigen Speicherort, und beide Anwendungen können gleichzeitig geöffnet sein. Ein Start wartet auf einen anderen Start desselben Produkts desselben Benutzers, solange dieser eine Version ablegt (ein Mutex je Produkt und Windows-Sitzung, bis zu zwei Minuten, dann Code 41). Gemeinsam sind den Produkten der Komponentenordner und die Registrierung der WKL-Komponenten für den Benutzer: Registriert eine Anwendung ein neueres Release, verwendet die andere es ebenfalls (eine ältere Anwendung läuft auf einem neueren Release weiter; siehe die Dokumentation der WKL Forms Object Library, Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen).