Letzte Änderung am 20. August 2021 by Christoph Jüngling
Im Teil 1 haben wir uns mit ein paar grundlegenden Überlegungen beschäftigt, Teil 2 thematisierte konkret die Frontend-/Backend-Trennung. Im dritten und letzten Teil der Reihe geht es nun endlich darum, wo (und wie) ich das Frontend meiner Access-Applikation denn bitte installieren sollte. Zusätzlich gibt es ein Setup-Script (Inno-Setup) zum Download, das ihr gerne frei verwenden und nach Belieben anpassen könnt.
Gehe zu Teil 1 – Teil 2 – Teil 3
In diesem Artikel
Allgemeines
Dass (und warum) wir das Frontend auf der lokalen Festplatte des Anwenders installieren sollten, ist inzwischen wohl hinreichend klar geworden. Doch auch dieser Speicherort lässt noch einige Varianten zu. Die übliche Stelle C:\Programme oder C:\Programme (x86) kommt aus einem bestimmten Grund leider nicht in Frage. Denn seit längerem verbietet Windows dem normalen Anwender, hier schreibend zuzugreifen. Das ist ein Sicherheitsfeature und bei normalen Programmen in Form von EXE-Dateien auch keine wesentliche Einschränkung (außer für Viren und Trojaner). Doch eine Access-Applikation besteht technisch aus der Datenbank mit allem Drum und Dran, und lokale Änderungen sind dabei durchaus an der Tagesordnung, z.B. wenn temporäre Tabellen genutzt werden sollen. Intern macht das Access auch gern mal.
Wenn ich nun eine ACCDB-Datei in einem der genannten Verzeichnisse installiere, erhalte ich beim Öffnen diese Meldung:
Schreibschutzmeldung
Auch wenn der Benutzer diese Meldung jedesmal ignoriert, ist sie doch recht nervig. Und wenn einer doch mal auf den “Speichern unter…”-Button klickt und genau dies tut, dann könnte er sich wundern, wenn er das am nächsten Morgen erneut machen will. Eine andere Lösung muss her.
Der “User Program Folder”
Neben den beiden oben bereits erwähnten und vermutlich bekannten Programm-Verzeichnissen bietet Windows noch ein weiteres Konzept an, den “user program folder”:
C:\Users\USERNAME\AppData\Local\Programs
Den Platzhalter USERNAME denkt man sich natürlich durch den jeweiligen Benutzernamen ersetzt. Dieses im Benutzerprofil liegende Verzeichnis unterliegt der Kontrolle des Users, weshalb zum Installieren keine Adminrechte erforderlich sind. Da der Benutzer hier auch Schreibrechte hat, kommt die obige Meldung ebenfalls nicht mehr.
Der Teil “Local” in der obigen Pfadangabe deutet aber darauf hin, dass dieser Teil des Benutzerprofils nicht im sogenannten “Roaming Profile” eingeschlossen ist, also nicht über einen Server an andere Rechner verteilt wird, auf denen ich mich unter Umständen gelegentlich einlogge. Die Installation unserer Access-Applikation muss also auf allen diesen Rechnern einmal durchgeführt werden.
Um dies einzustellen, wähle in InnoSetup folgende Einstellungen aus:
- DefaultDirName={userpf}\{#MyAppName}
- PrivilegesRequired=lowest
Der Ausdruck “{userpf}” steht eben für “user program folder” und wird bei der Installation durch den persönlichen Programmordner des angemeldeten Users ersetzt.
Dass die Privilegien auf “lowest” gesetzt werden, ist dann auch nur logisch, denn für diesen Ordner benötigen wir ja keinerlei Adminrechte. In der Folge kommt dann vom Windows-Sicherheitssystem auch nicht mehr die Anfrage, ob man dieser Installation vertraut. Das finde ich persönlich zwar nicht so glücklich, aber mich fragt ja keiner.
Das Script
Der Rest des Innosetup-Scripts ist eigentlich ziemlich “normal”, so dass ich darauf nicht weiter eingehen will. Lediglich die Änderung des Willkommens-Textes scheint mir erwähnenswert, da ich hier mittels der [Messages]-Rubrik die Standardtexte um Datum und Git-Hash ergänzt habe. Das ist natürlich nicht zwingend notwendig, mir erscheint es aber zweckmäßig, da der Benutzer sofort bei Beginn der Installation die wertvolle Information bekommt, wie alt diese Version ist. Natürlich sollten diese Informationen im Script automatisch angepasst werden und vor allem auch in der Applikation selbst abrufbar sein.
Ebenso habe ich den üblichen Textteil “bitte alles andere beenden, bevor die Installation fortgesetzt wird” entfernt, da dies für unsere Access-Applikation nicht erforderlich ist. Damit sieht der Willkommens-Dialog z.B. so aus:
Allerdings könnte und sollte man eben diese Applikation vorher beenden, falls sie denn läuft. Wie das geht, erkläre ich gelegentlich mal in einem anderen Artikel.
Download
Das Script kann aus diesem Projekt bei Gitlab heruntergeladen werden. Dies kann entweder durch ein Cloning mittels Git oder TortoiseGit erfolgen, oder durch den Download des letzten Standes über den Button links neben dem blauen “Klonen”-Button.
Neueste Kommentare