Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen

Bringen Sie eine Access-Anwendung (ACCDB oder ACCDE, Vollversion von Access oder Access Runtime), die WKL-Steuerelemente verwendet, auf die PCs ihrer Benutzer.

Voraussetzungen: ein beliebiges Release der WKL Forms Object Library; die Beispiele verwenden <version> für den Ordner des Release.

Jeder Benutzer-PC braucht vier Dinge, in dieser Reihenfolge:

1. Die .NET 10 Desktop Runtime in der Bitversion von Office (bzw. der Access Runtime).
2. Die Dateien des Release in dieser Bitversion, in einem lokalen Ordner, der bestehen bleibt.
3. Die Registrierung von Wkl.Forms.ObjectLibrary.dll für jeden Windows-Benutzer, der die Anwendung startet.
4. Die Anwendung selbst, gebaut mit demselben Release, an einem vertrauenswürdigen Speicherort.

Das folgende Skript führt die Schritte 2 und 3 aus; Schritt 1 ist das Installationsprogramm von Microsoft, Schritt 4 Ihre eigene Verteilung des Frontends. Ohne Skript übernimmt der Bootstrapper aus dem Paket die Schritte 2 und 3 (siehe Hinweise).

Prüfliste je PC:

Skript für die Schritte 3 und 4 (PowerShell, von jedem Benutzer ausgeführt; keine Administratorrechte). Setzen Sie $Source auf den Ordner des Release auf Ihrer Freigabe und $Bitness für ein 32-Bit-Office auf x86:

$Version = '1.59'                                 # the release folder (<version>)
$Bitness = 'x86'                                  # 'x64' for 64-bit Office
$Source  = "\\server\share\WKL Forms Object Library\$Version\$Bitness"
$Target  = Join-Path $env:LOCALAPPDATA "WKL\Access Components\$Version\$Bitness"
 
# Only the Access of this session: on a terminal server other users' Access processes are visible too.
$session = (Get-Process -Id $PID).SessionId
Get-Process MSACCESS -ErrorAction SilentlyContinue | Where-Object SessionId -eq $session | ForEach-Object {
    throw 'Close Access first: it keeps a loaded DLL until it exits.'
}
New-Item -ItemType Directory -Force $Target | Out-Null
Copy-Item (Join-Path $Source '*') $Target -Force
 
$regsvr32 = if ($Bitness -eq 'x86') { "$env:windir\SysWOW64\regsvr32.exe" } else { "$env:windir\System32\regsvr32.exe" }
$process = Start-Process $regsvr32 -ArgumentList '/s', '/n', '/i:user', "`"$Target\Wkl.Forms.ObjectLibrary.dll`"" -Wait -PassThru
if ($process.ExitCode -ne 0) { throw "regsvr32 failed with exit code $($process.ExitCode)." }
'WKL Forms Object Library registered.'

Führen Sie das Skript aus einem Anmeldeskript oder einem Softwareverteilungswerkzeug im Kontext des Benutzers aus, nicht als anderer Benutzer: Die Registrierung landet in der Registrierung des Benutzers, der das Skript ausführt.

Skript für Schritt 5, im selben Kontext: Set-AccessTrustedLocation.ps1 schreibt den Eintrag, den auch das Dialogfeld des Trust Centers schreibt (pro Windows-Benutzer, keine Administratorrechte), und entfernt ihn mit -Remove wieder:

$Front = Join-Path $env:LOCALAPPDATA 'Contoso\Orders'      # the folder of the front end
& "\\server\share\WKL Forms Object Library\$Version\tools\deploy\Set-AccessTrustedLocation.ps1" -Path $Front

Ein Ordner auf einer Netzwerkfreigabe braucht zusätzlich -AllowNetworkLocations; das erlaubt vertrauenswürdige Speicherorte im Netzwerk für alle Einträge des Benutzers. Ein lokaler Ordner für das Frontend vermeidet das. Per Richtlinie festgelegte Speicherorte haben Vorrang: Hat ein Administrator vertrauenswürdige Speicherorte abgeschaltet, warnt das Skript, dass sein Eintrag keine Wirkung hat.

• Ohne Skript: der Bootstrapper. Das Paket enthält bootstrapper\Wkl.Bootstrapper.exe, einen Starter, der diese Schritte beim Start der Anwendung für jeden Benutzer ausführt – er kopiert die Version in das Profil des Benutzers, registriert die WKL-Komponenten für den Benutzer, macht den Ordner zu einem vertrauenswürdigen Speicherort und startet Access, ohne Administratorrechte. Siehe Anwendung mit dem Bootstrapper ausliefern. Ab Release 1.56.2 enthält das Paket den Bootstrapper 2.0 und neben jeder DLL eine registration.json (die Registrierung pro Benutzer als Daten): Der Bootstrapper 2.0 schreibt und entfernt diese Schlüssel selbst, statt regsvr32 aufzurufen, und hält ein Release registriert, solange eine installierte Anwendung es noch braucht.
• ACCDE je Release. Bauen Sie die ACCDE aus der ACCDB, während das Release registriert ist, das die Benutzer erhalten. Eine mit einem älteren Release gebaute Datenbank öffnet sich mit einer neueren Registrierung (Access löst den Verweis beim Öffnen der Datenbank auf); eine ACCDE lässt sich auf dem PC des Benutzers jedoch nicht erneut kompilieren. Bauen Sie daher eine neue ACCDE, sobald Sie Member eines neueren Release verwenden.
• Reihenfolge eines Updates: erst die Komponenten, dann die Datenbank. Eine ACCDE, die bei registriertem Release gebaut wurde, läuft auch bei einem registrierten neueren Release (der Verweis zeigt dann auf die neuere Datei und ist intakt). Umgekehrt wird es nicht unterstützt: Eine ACCDE, die bei registriertem neuerem Release gebaut wurde, kann auf einem PC, der noch das ältere hat, einen defekten Verweis haben (TYPE_E_LIBNOTREGISTERED), und ein Formular mit Ereignissen eines WKL-Steuerelements scheitert mit Fehler 459. Auf einem PC mitten im Update funktionieren die neuen Komponenten mit der alten Datenbank, die neue Datenbank mit den alten Komponenten dagegen nicht. Verteilen Sie die Komponenten vor der Datenbank, die mit ihnen gebaut wurde.
• Access Runtime. Die Steuerelemente laufen in der Access Runtime wie in der Vollversion von Access. Die Runtime hat keine Add-Ins: Der Menüeintrag des Designers des Verknüpfungsmanagers (Datenbanktools › Add-Ins) ist nur ein Werkzeug für den Entwickler; Anwendungen rufen WklLinkManager aus ihrem eigenen Code auf.
• Mehrere Windows-Benutzer an einem PC (Terminalserver, gemeinsam genutzte PCs): Jeder Benutzer führt das Skript einmal aus. Eine Registrierung für alle Benutzer eines PCs (regsvr32 als Administrator ohne /n /i:user) wird in diesem Release nicht unterstützt.
• Vertrauenswürdiger Speicherort. Das VBA der Anwendung läuft nur an einem vertrauenswürdigen Speicherort oder in einer vertrauenswürdigen Datenbank. Außerhalb davon fragt Access mit seiner Sicherheitswarnung nach (Standard-Makroeinstellung, ACCDE) oder schaltet den Code kommentarlos ab (strengere Einstellungen, eine ACCDB in der Vollversion) – siehe Die Anwendung öffnet sich, aber ihr Code läuft nicht. Ein Speicherort umfasst Unterordner nur mit -AllowSubfolders; Test-AccessTrust.ps1 aus dem Paket prüft einen PC vor dem ersten Start. Die ActiveX-Einstellung Alle Steuerelemente ohne Benachrichtigung deaktivieren stoppt die WKL-Steuerelemente auch an einem vertrauenswürdigen Speicherort (Access-Fehler 2926); die anderen ActiveX-Optionen nicht – siehe die oben genannte Seite zur Fehlerbehebung.
• Update. Für ein Update schließen Sie Access auf dem PC, führen das Skript mit der neuen Version aus und ersetzen das Frontend durch das mit ihr gebaute. Löschen Sie danach den Ordner der alten Version.
• Bitversion. Unterstützt werden 32-Bit- und 64-Bit-Access.

• Freigegebenes Paket installieren – dieselben Schritte auf einem Entwicklungs-PC, mit der Liste der Dateien
• Die .NET 10 Desktop Runtime ist nicht installiert
• Ein WKL-Steuerelement oder der Verweis fehlt (falsche Bitversion)
• Access meldet, dass eine andere .NET-Version geladen ist
• Die Anwendung öffnet sich, aber ihr Code läuft nicht