WKL Bootstrapper: Installer und Starter je Benutzer für Access-Anwendungen

Der WKL Bootstrapper bringt ein neues Release einer Anwendung zu jedem Benutzer – ohne Administratorrechte und ohne Besuch an jedem PC. Der Benutzer startet eine EXE-Datei; sie installiert die vom Herausgeber ausgelieferte Version in das Benutzerprofil, registriert alles, was die Anwendung für diesen Benutzer braucht, und startet sie. Gedacht ist er für Access-Frontends, die mit der WKL Forms Object Library gebaut sind; jedes andere Programm und jedes Dokument startet er auf dieselbe Weise.

Das Produkt heißt Bootstrapper; sein Programm ist Wkl.Bootstrapper.exe, und die Seiten nennen es kurz den Starter, denn als solcher tritt es für den Benutzer in Erscheinung.

Bis Release 2.3.1 hieß das Produkt WKL Access Bootstrapper, bis Release 2.4.1 sein Programm Wkl.Access.Bootstrapper.exe. Ein Ordner, in dem das Programm noch unter diesem Namen liegt, funktioniert weiter: Ist kein Starter angegeben, nimmt der Starter Wkl.Bootstrapper.exe und, wenn es fehlt, den früheren Namen.

Unterstützte Konfiguration: Windows 11 mit Microsoft Access (Microsoft 365) in 32 oder 64 Bit. Windows 10 und Computer, die Programme im Benutzerprofil mit AppLocker oder Windows Defender Application Control einschränken, werden in diesem Release nicht unterstützt. Was der Starter grundsätzlich nicht leistet, steht unter Grenzen.

Ein Access-Frontend ist eine Datei, und jeder Benutzer arbeitet mit einer eigenen Kopie: Microsoft empfiehlt eine aufgeteilte Datenbank, in der jeder Benutzer über eine lokale Kopie der Front-End-Datenbank mit den Daten arbeitet. Dann gehen nur die Daten über das Netzwerk, und eine Beschädigung der Datei beschränkt sich in der Regel auf die Kopie der Front-End-Datenbank, die der Benutzer geöffnet hatte (Aufteilen einer Access-Datenbank).

Mit dieser Kopie allein ist es nicht getan. Bei jedem Release gilt:

• Die Kopie jedes Benutzers muss ersetzt werden, während einige Benutzer die alte noch geöffnet haben.
• Die WKL Forms Object Library (oder andere ActiveX- und COM-Komponenten) müssen in der Bitbreite des installierten Office registriert werden.
• Der Ordner muss ein vertrauenswürdiger Speicherort sein, sonst führt Access den Code nicht aus.
• ODBC-Treiber, Datenquellen und die .NET-Runtime müssen vorhanden sein.

Von Hand bedeutet das einen Besuch an jedem PC, meist mit Administratorrechten. Ein fehlerhaftes Release lässt sich nicht einfach zurücknehmen, und hinterher weiß niemand, was wo installiert wurde.

Der Starter übernimmt das Modell von ClickOnce (je Benutzer, ohne Administratorrechte, Updates aus der Quelle des Herausgebers) und die Gründlichkeit von Windows Installer (ein Nachweis jeder Datei und jedes Werts in der Registrierungsdatenbank, gezählte gemeinsame Komponenten, Rollback, Entfernen über „Apps“). Die IT installiert nur den Starter selbst, einmal; jedes spätere Release erreicht die Benutzer über ihn.

graph TD
    U["Benutzer startet Wkl.Bootstrapper.exe"] --> P["Projektdatei lesen (bootstrapper.json oder die mit /RUNCFG genannte Datei)"]
    P --> S["Gegen die Quelle auflösen (Dateien, Version, Registrierungsdatenbank, Startziel)"]
    S -- "Quelle nicht erreichbar oder Auslieferung nicht vertrauenswürdig" --> I["Installierte Version starten"]
    S --> C["Bedingungen prüfen (Access, .NET, ODBC, Dateien, Registrierungsdatenbank, Programme)"]
    C -- "nicht erfüllt" --> E["Fehlerfenster mit Code und Diagnose"]
    C --> T
    subgraph TX["Eine Transaktion"]
        T["Version installieren: Dateien, Komponenten, Treiber, Registrierungsdatenbank, Dateitypen, Verknüpfungen, INI, vertrauenswürdiger Speicherort, Eintrag unter Apps, afterInstall-Aktionen"]
        J[("installer.db - Journal jedes Schritts")]
        T -- "erfasst jeden Schritt" --> J
    end
    T -- "ein Schritt scheitert" --> R["Jeden Schritt in umgekehrter Reihenfolge zurückrollen"]
    T --> K["Versionen über keepVersions hinaus entfernen"]
    K --> G["Ziel starten (ein Programm, ein Dokument über seinen Dateityp oder Access mit der Datenbank)"]

• Projektdatei (bootstrapper.json neben der EXE-Datei oder eine andere .json-Datei im selben Ordner, die mit /RUNCFG <file> genannt wird): was der Starter installiert und startet – Dateien, Werte in der Registrierungsdatenbank, Verknüpfungen, Dateitypen, eine INI-Datei, Aktionen, Bedingungen und das Startziel. Vertrag: Die Projektdatei (Format 2).
• Quelle (die Auslieferung): der Ordner oder die Freigabe, die der Herausgeber befüllt. Ein Start liest daraus und schreibt nie hinein.
• Version: Jede ausgelieferte Version erhält einen eigenen Ordner im Profil; Dateien darin werden einmal abgelegt und nie ersetzt.
• Gemeinsame Komponenten: WKL Forms Object Library, ODBC-Treiber, eine private .NET-Runtime und andere Teile außerhalb des Ordners einer Version werden je Release vorgehalten und je Produktversion gezählt; sie bleiben, solange irgendein Produkt des Benutzers sie braucht.
• Installer-Datenbank (%LOCALAPPDATA%\WKL\Installer\installer.db, eine je Benutzer): der Nachweis jedes Produkts, jeder Version, jeder Komponente und jeder Ressource sowie das Journal der laufenden Installation.
• Codes: Jeder Start endet mit einem Code – 0 gestartet; 1x Konfiguration, 2x Access, 3x Voraussetzungen, 4x Installation, 5x Vertrauen, 6x Start. Dieselbe Zahl erscheint im Fehlerfenster, in der Diagnose und als Exitcode.

Alles wird unterhalb der Ordner des Benutzers und unter HKEY_CURRENT_USER geschrieben; der Starter fordert nie erhöhte Rechte an. Einzelheiten: Der Installer.

Der Starter hat drei Arten von Lesern; jede hat ihren eigenen Einstieg.

Sie bauen die Anwendung und wollen sie auf die PCs der Benutzer bringen.

1. Schreiben Sie eine Projektdatei aus Vorlagen: Projekt aus Vorlagen erstellen.
2. Tragen Sie ein, was sie installiert und startet – eine Access-Anwendung wie in Anwendung mit dem Bootstrapper ausliefern, jedes andere Programm wie in Beliebiges Programm mit dem Starter starten.
3. Prüfen Sie die Datei mit Wkl.Bootstrapper.exe /check <file> und probieren Sie sie mit /whatif <file> aus; dieser Befehl meldet jede Prüfung und was ein Start installieren würde, ohne etwas zu ändern.
4. Bei Bedarf: Access-Anwendung für 32-Bit- und 64-Bit-Office ausliefern, Private .NET-Runtime ausliefern, Signierte Auslieferung veröffentlichen, Anwendung ohne bleibende Installation starten.

Die Projektdatei lässt sich auch im WKL Bootstrapper Manager bearbeiten, einer eigenen Access-Anwendung, die dieselben Prüfungen ausführt und das MSI baut; sie ist im „Benutzerhandbuch WKL Bootstrapper Manager“ der Dokumentation des WKL Bootstrapper Manager beschrieben.

Sie verwalten die PCs und entscheiden, was installiert werden darf. Der Starter braucht für kein Release Administratorrechte; nur der Starter selbst wird einmal installiert, als Windows-Installer-Paket, das aus der Projektdatei gebaut wird: Starter per MSI verteilen. Was der Starter auf einem PC schreibt, steht in Der Installer.

Sie betreuen eine Anwendung für ihre Benutzer.

• /settings öffnet das Einstellungsfenster: ob die Anwendung starten kann, die installierten Versionen (eine frühere starten, eine neu kopieren, alte entfernen), die Registrierung der Komponenten, die Diagnose, das Protokoll und die Einträge der Projektdatei, die ein Anwendungsadministrator ändern darf.
• /diagnose (/diagnose /json) meldet, was ein Start vorfinden würde, ohne etwas zu ändern; /list (/list /json) zeigt die installierten Versionen und Komponenten mit der Zahl ihrer Verwender.
• /repair installiert, was fehlt, ohne zu starten; /uninstall entfernt das Produkt.
• Das Protokoll liegt unter %LOCALAPPDATA%\WKL\<product>\Logs\bootstrapper.log.
• Ein fehlgeschlagener Start zeigt einen Code; Fehlercodes des Starters hat je Code eine Seite mit Ursache und Lösung.

Alle Befehle und Exitcodes: Der Installer.

• Der Starter installiert nichts, was Administratorrechte braucht: keine systemweiten Treiber, keine Access Runtime, keine computerweiten Registrierungen. Das sind Voraussetzungen, die die IT bereitstellt; der Starter prüft sie und meldet eine fehlende mit ihrem Code.
• Er baut die Anwendung nicht; eine Access-Anwendung wird mit dem WKL Office SDK gebaut.
• Zwei Starter desselben Windows-Benutzers, die im selben Moment installieren, werden nicht nacheinander ausgeführt; starten Sie jeweils nur einen.
• Eine Quelle über HTTP oder HTTPS wird nicht unterstützt; die Quelle ist ein Ordner oder eine Freigabe.
• Die Signatur einer Auslieferung deckt die Programme nicht ab, die actions ausführen; was sie nicht abdeckt, steht unter Signierte Auslieferungen.
• Weiteres unter Grenzen des Installers.

Nur relevant, wenn Benutzer bereits von einem früheren Starter versorgt werden.

• StarterPro, der Vorgänger dieses Starters mit seiner Konfiguration StarterPro.config.xml: /import-starterpro wandelt die Konfiguration in eine Projektdatei um. Siehe Vom bisherigen Starter umsteigen.
• Starter 1.0 (Projektdateien im Format 1): werden weiterhin gelesen und gestartet. 2.x übernimmt, was 1.0 abgelegt hat, und entfernt es wie seine eigenen Teile (Übernahme des Starters 1.0). Für Auslieferungen, die noch auf dem Weg von 1.0 laufen: Was der Starter schreibt und meldet und Anwendung von einem PC entfernen.

• Die Projektdatei (Format 2) – jeder Eintrag, die Platzhalter, Aktionen und Bedingungen
• Der Installer – Transaktion, Zählung, Release-Regel, Befehle, die Installer-Datenbank
• Fehlercodes des Starters
• Sicherheit und Pflichten des Herstellers – eine Schwachstelle melden, Pflichten nach der Cyberresilienz-Verordnung und gegenüber NIS-2-Einrichtungen, Weg zur Konformität
• tools\Export-ComRegistration.ps1 im Release-Ordner erfasst die Registrierung eines COM-Servers als registration.json auf dem Computer des Herausgebers; der Starter schreibt sie für den Benutzer, statt die eigene Registrierung des Servers auszuführen.