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.

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:

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

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

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

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.

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

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 Starter macht Frontends zu einem vertrauenswürdigen Speicherort von Access für den Benutzer, mit Unterordnern, damit sich die Kopien ohne Sicherheitswarnung öffnen:

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.

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

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

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

• Anwendung mit dem Bootstrapper ausliefern
• Anwendung von einem PC entfernen
• Fehlercodes des Starters