WKL Office SDK installieren

Sie richten das WKL Office SDK auf einem Entwicklungsrechner oder einem Build-Rechner ein, damit wkl-office und dotnet build einer .acproj dort funktionieren.

Voraussetzungen: Windows 11, Microsoft 365 Access (32 Bit), installiert für den Benutzer, der baut, git im PATH und die .NET 10 Runtime (dotnet --list-runtimes listet Microsoft.NETCore.App 10.x auf). Für dotnet build zusätzlich das .NET 10 SDK. Das Access-Add-In läuft innerhalb von Access und benötigt die .NET 10 Desktop Runtime in der Bitbreite von Office (Microsoft.WindowsDesktop.App 10.x; für 32-Bit-Office die x86-Runtime, die C:\Program Files (x86)\dotnet\dotnet.exe --list-runtimes auflistet).

Unterstützte Konfiguration dieses Releases: Windows 11 mit Microsoft 365 Access in 32 oder 64 Bit. Access 2016, 2019 und 2021, Windows 10 und ein Build-Rechner, auf dem nur die Access Runtime installiert ist, werden nicht unterstützt.

Das SDK ist ein Ordner: bin enthält wkl-office.exe, msbuild die MSBuild-Tasks und ihre Targets, addin das Entwickler-Add-In für Access in beiden Bitbreiten, bootstrapper-manager den Bootstrapper Manager, mit dem Sie den Starter einer Auslieferung einrichten, docs/public diese Dokumentation, SECURITY.de.md und MANUFACTURER.de.md (auch auf Englisch und Slowenisch), wie Sie eine Schwachstelle melden, wer der Hersteller ist und bis wann die Fassung unterstützt wird, und sbom.cdx.json die Software-Stückliste des Pakets (CycloneDX 1.6). Durch das Kopieren wird nichts registriert, und Administratorrechte sind nicht erforderlich; das Add-In wird nur auf Anforderung registriert, und zwar für den aktuellen Benutzer. Das Werkzeug automatisiert das installierte Access prozessübergreifend (out of process), daher bedient derselbe Ordner 32-Bit- und 64-Bit-Office.

1. Kopieren Sie den Paketordner an einen Ort Ihrer Wahl, zum Beispiel C:\Tools\WklOfficeSdk.

2. Nehmen Sie seinen Ordner bin in den PATH Ihres Benutzers auf:

   $bin = 'C:\Tools\WklOfficeSdk\bin'
   [Environment]::SetEnvironmentVariable('Path', [Environment]::GetEnvironmentVariable('Path', 'User') + ';' + $bin, 'User')

3. Öffnen Sie ein neues Terminal und prüfen Sie den Rechner anhand eines Projekts:

   wkl-office check C:\Work\Kunden\Kunden.acproj

   check nennt das gefundene Access mit seiner Bitbreite sowie jeden fehlenden Verweis und jeden fehlenden ODBC-Treiber.

4. Für dotnet build importieren Sie die Targets am Ende der Projektdatei:

     <Import Project="C:\Tools\WklOfficeSdk\msbuild\Wkl.Office.Sdk.targets" />
   </Project>

5. Für die Registerkarte im Menüband und den Arbeitsbereich in Access registrieren Sie das Add-In, während Access geschlossen ist (siehe Access-Add-In verwenden):

   wkl-office addin install

   Beim nächsten Start von Access steht die Registerkarte WKL SDK im Menüband:

   

   *Die Registerkarte WKL SDK mit ihren Gruppen 1 bis 6; was sie enthalten, steht in Access-Add-In verwenden.*

   Derselbe Befehl installiert den Bootstrapper Manager für Ihren Benutzer nach %LOCALAPPDATA%\Programs\WKL\Bootstrapper Manager\<version>; er meldet, ob er ihn kopiert hat oder ob diese Version schon vorhanden war. Der Bootstrapper Manager braucht die WKL Forms Object Library 2.0 oder höher und WKL Office JSON 2.0 oder höher, für Ihren Benutzer registriert; mit älteren Komponenten zeigt er [key] statt seiner Texte.

   Außerdem ordnet er Projektdateien dem SDK zu: Ein Doppelklick auf eine .acproj im Explorer öffnet die Anwendung zum Entwickeln in Access, ohne dass Startformular oder AutoExec laufen, und baut sie zuerst, wenn es noch keine Datenbank gibt (`open`). Ein Doppelklick auf die .accdb startet die Anwendung weiterhin so, wie ihre Benutzer sie sehen. Das Menü einer Projektdatei hat dann das Untermenü „WKL Office SDK“ (unter Windows 11 unter „Weitere Optionen anzeigen“). Beim ersten Doppelklick fragt Windows einmal, mit welcher App .acproj-Dateien geöffnet werden: Wählen Sie „WKL Office SDK“ und „Immer“.

• Paket prüfen. Jede Programmdatei des Pakets (EXE und DLL) trägt die Authenticode-Signatur von EMSR DATA, D.O.O. mit Zeitstempel, und SHA256SUMS nennt die SHA-256-Prüfsumme jeder anderen Datei. Bevor Sie den Ordner in den PATH aufnehmen, prüfen Sie beides:

  Get-AuthenticodeSignature C:\Tools\WklOfficeSdk\bin\wkl-office.exe | Format-List Status, SignerCertificate
  Set-Location C:\Tools\WklOfficeSdk
  Get-Content SHA256SUMS | ForEach-Object { $hash, $file = $_ -split '  ', 2; if ((Get-FileHash -LiteralPath $file).Hash -ne $hash) { "changed: $file" } }

  Status muss Valid sein und der Signierer EMSR DATA, D.O.O.; der zweite Befehl gibt nichts aus, wenn keine Datei verändert ist.

• Was das SDK auf Ihrem Rechner ausführt. Ein Build führt VBA-Code der Quellen aus: Die Abschlussfunktion des Projekts (Finish) und die Funktionen der WKL-Modelle laufen im Access des Builds. Wer die Quellen ändern darf, kann also Code auf dem Rechner ausführen, der sie baut: Bauen Sie nur Quellen, denen Sie vertrauen, und lassen Sie einen Build-Agenten nur geprüfte Zweige bauen. Eine Datenbank, die das SDK selbst öffnet (Export, validate, call, test), öffnet es als Kopie ohne Startformular; eine Datenbank mit AutoExec-Makro lehnt es ab. git, svn, Visual Studio Code und PowerShell findet das SDK über den PATH des Benutzers; wer den PATH ändern kann, bestimmt, welches Programm startet – wie bei jedem Befehlszeilenwerkzeug.
• Build-Rechner. Access muss für das Konto, unter dem der Build läuft, installiert und aktiviert sein, und der Build benötigt eine Desktopsitzung dieses Kontos (Access läuft nicht als Dienst): Ein Build-Agent läuft als interaktiver Prozess eines angemeldeten Benutzers. Die Verweise der Anwendung (WKL Forms Object Library, WKL Office JSON …) müssen für dieses Konto registriert sein, und zwar in der Bitbreite von Access. Module gelangen in der ANSI-Codepage von Windows nach Access („Sprache für Unicode-inkompatible Programme“): Der Rechner benötigt eine Codepage, die jedes Zeichen der Module enthält. Mit ConnectionProfile verbindet sich der Build mit den Datenquellen; er benötigt dann die Treiber, Netzwerkzugriff und eine Anmeldung ohne Rückfrage. Das SDK liefert kein Betriebsverfahren für Build-Agents (automatische Anmeldung, gesperrter Bildschirm, Überwachung); richten Sie das mit den üblichen Mitteln Ihres Build-Systems ein.
• Aktualisierung. Ersetzen Sie den Ordner; die Projekte ändern sich nicht, ein Projekt nennt keine Version des SDK. Ist das Add-In registriert, schließen Sie zuerst Access: Access hält die Dateien des Add-Ins geöffnet, solange es läuft. Legen Sie die neue Version stattdessen in einen eigenen Ordner (etwa einen Ordner je Version), stellen Sie den PATH-Eintrag auf dessen Ordner bin um und entfernen Sie den alten Eintrag; sonst starten neue Terminals weiter die alte Version. Welche wkl-office.exe ein Terminal startet, zeigt (Get-Command wkl-office).Source. wkl-office addin install legt eine neuere Version des Bootstrapper Managers in einen eigenen Ordner neben die bisherige und überschreibt eine installierte Version nie, denn Access speichert in der Datei Ihre Änderungen; das SDK öffnet die höchste Version. Führen Sie wkl-office addin install der neuen Version einmal aus; danach verwenden das Add-In und der Doppelklick auf Projektdateien den neuen Ordner.
• Umstieg vom WKL Access SDK (0.4 und älter). Ab 0.5 heißt das SDK WKL Office SDK und sein Befehl wkl-office; wkl-access.exe gibt es nicht mehr. Stellen Sie Skripte, .vscode\tasks.json und Build-Definitionen, die wkl-access aufrufen, auf wkl-office um, und ändern Sie einen Import von Wkl.Access.Sdk.targets in Wkl.Office.Sdk.targets. Projekte, Befehle, Optionen und Exitcodes bleiben gleich. Führen Sie einmal wkl-office addin install aus, damit das Add-In aus dem neuen Ordner registriert ist.
• Entfernen. Führen Sie wkl-office addin remove --all aus, wenn das Add-In registriert war: Es entfernt das Add-In und die Einstellungen des SDK für Ihren Benutzer (HKEY_CURRENT_USER\Software\The White Knight Labs\Access Framework\Sdk); ohne --all bleiben die Einstellungen für eine spätere Installation erhalten. Löschen Sie danach den Ordner und seinen Eintrag im PATH. wkl-office addin remove lässt den Bootstrapper Manager stehen; löschen Sie %LOCALAPPDATA%\Programs\WKL\Bootstrapper Manager, um ihn zu entfernen (eine Version vor 2.0 liegt unter %LOCALAPPDATA%\Programs\WKL\Starter Configurator).

• Tutorial: Access-Anwendung unter Versionsverwaltung stellen
• Mit dotnet build bauen
• Befehlszeilenreferenz