Christoph Jüngling, https://www.juengling-edv.de
Im ersten Teil haben wir uns mit den Grundlagen eines Setups beschäftigt, nun geht es “in medias res”. Dieser Teil beinhaltet die konkrete Umsetzung der Gedanken. Wir schauen uns das Setup-Script im Detail an und lernen, was die einzelnen Bestandteile bedeuten. Wir werden neben der Access-Datenbank auch Startmenü-Einträge und Desktop-Icons anlegen. Die Setup-Sprache wird variabel gemacht, es darf eine Lizenzvereinbarung geben und es wird für eine ordnungsgemäße Deinstallation gesorgt.
Organisatorisches
Vor der Umsetzung sollten wir uns kurz überlegen, was wir erreichen wollen, denn “wer nicht weiß, wo er hin will, darf sich nicht wundern, wenn er ganz woanders ankommt”.
Gehen wir zunächst von einem Minimalsetup aus. Was wäre das Minimum, das ein Access-Entwickler von “seinem” Setup erwartet
- Einspielen der .accdb/.accde-Datei
- Einrichten von Startmenü- und Desktop-Icons
- Vorbereitung der Deinstallation
Als kleine Erweiterung behalten wir uns dann noch Folgendes vor:
- Zu Beginn Darstellung von Betahinweis oder der Lizenzbedingungen, Bestätigung anfordern
- Zu Beginn Darstellung im Stile “Was ist neu in diesem Release”
- Abschließend eine Readme-Datei anzeigen
Das ist zunächst sicher nicht viel, und wer den ersten Teil dieser kleinen Artikelserie gelesen hat, hätte sicher noch einiges mehr erwartet. Aber machen wir es uns zu Beginn nicht zu schwer, Erweiterungen sind ja jederzeit möglich.
Ich erlaube mir, an dieser Stelle noch ein anderes hilfreiches Werkzeug des Softwareentwicklers zu erwähnen. Wahrscheinlich werden Sie dies ohnehin nutzen, dann ist es nur eine Erinnerung, dass das auch für unser Setup-Script funktioniert.
Es geht um Versionsverwaltung, auch Quellcodeverwaltung genannt. Unser Setup-Script ist im “Quellcode” schließlich auch nur ein wenig “plain text”, sodass dieses Script genauso mit Git (oder einer anderen Quellcodeverwaltung) verwaltet werden kann – und sollte.
Die .exe-Datei würde ich dabei von der Verwaltung ausnehmen (Git: *.exe in die .gitignore-Datei). Einerseits wird sie recht groß sein, andererseits ist sie redundant, denn alles, was zu ihrer Erstellung benötigt wird, ist ja ohnehin komplett versioniert.
Grundprinzip des Setup-Scripts
Das Setup-Script ähnelt in weiten Bereichen streng genommen mehr einer .ini-Datei als einem Programm. Ich will es dennoch weiterhin “Script” nennen, da der Begriff durchaus als gängig gelten kann. Die Festlegungen in diesem Script werden vom InnoSetup-Compiler interpretiert, der letztlich dann das eigentliche Setup (eine .exe-Datei) zusammenbaut. Ausgeliefert wird dann nur diese .exe-Datei.
Wie bei einer .ini-Datei üblich haben wir Sektionen mit Überschriften in eckigen Klammern wie zum Beispiel [Setup] gleich zu Beginn.
Innerhalb dieser Sektionen stehen dann zahlreiche Key-Value-Einträge im Format Key = Value.
Beginnt eine Zeile mit einem Semikolon, wird diese komplett als Kommentarzeile interpretiert, also nicht für die Setup-Erstellung berücksichtigt. Dadurch können wir bestimmte Einträge vorbereiten und bei Bedarf aktivieren oder deaktivieren. Nur ein erneuter Compilerlauf ist dann erforderlich.
Wer ein neues Setup erstellen will, kann dies sowohl über InnoSetup selbst als auch über eine der im ersten Teil bereits angesprochenen GUIs tun. Dort ist in der Regel ein Assistent enthalten, mit dessen Hilfe das Grundgerüst schnell eingerichtet werden kann.
Da die Bedienung solcher Assistenten zumeist sehr intuitiv ist, will ich diese hier nicht näher besprechen, sondern lieber auf die Eintragungen im Script selbst eingehen. Ob Sie das Script mittels Assistenten oder von Hand erstellen oder einfach das am Ende dieses Artikels bereitgestellte fertige Script verwenden, bleibt dabei Ihnen überlassen.
Zu Beginn definieren wir in der Sektion [Setup] den Namen des zu installierenden Programms und einige weitere organisatorische Dinge:
[Setup] AppId=TestSetup AppName=My Awesome AccessApp AppVersion=1.0.0 AppVerName=AccessApp v1.0.0 AppPublisher=Vorname Name AppPublisherURL=https://www.meine-homepage.de AppSupportURL=https://www.meine-homepage.de AppUpdatesURL=https://www.meine-homepage.de
Dadurch werden Name und Version der zu installierenden Software genannt, ebenso Name und Website des Herausgebers und zwei URLs für Support und Updates. Die AppId hat dabei eine Sonderstellung, denn diese Information wird in der Registry als Bezeichnung für den Uninstall-Bereich eingetragen (siehe Bild 1). Hier finden Sie detaillierte Informationen über die Deinstallation.
Bild 1: Setup-Eintrag in der Registry
Anhand dieser Bezeichnung erkennt InnoSetup, ob es sich um eine Erstinstallation oder ein Update handelt. Dementsprechend sollte dieser Eintrag im Laufe des Projektes nicht mehr verändert werden!
Anstelle eines sprechenden Namens kann hier natürlich auch eine GUID verwendet werden. Die Compiler-GUI und auch Inno Script Studio besitzen zu deren Erzeugung einen Menübefehl.
Hierbei sehen wir bereits, dass einige Informationen mehrfach eingetragen werden. Zur besseren Übersicht bietet sich daher ein Verfahren an, das wir bereits vom Programmieren her kennen.
Wann immer wir eine immer gleiche Information an mehreren Stellen des Programms verwenden müssen, definieren wir eine globale Konstante und verwenden in der Folge dann nur noch diese anstelle des tatsächlichen Wertes. So ist eine Änderung des Wertes schnell gemacht und die Semantik ist auch sofort klar. Das geht natürlich auch in InnoSetup.
Konstanten im Setup-Script
Die Definition der Konstanten erfolgt dabei zwingend am Anfang des Script vor der [Setup]-Sektion nach folgendem Muster:
#define MyAppName "My Awesome AccessApp" #define MyAppVersion "1.0.0" #define MyAppPublisher "Christoph Jüngling" #define MyAppURL "https://www.meine-homepage.de" #define MyAppExeName "Testdatenbank.accdb"
Nun können wir das obige Script entsprechend überarbeiten. Dabei werden die Konstanten nach dem Muster {#NameDerKonstante} an der Stelle eingefügt, wo deren Wert stehen soll.
[Setup]
AppId={#MyAppName}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
AppVerName={#MyAppName} v{#MyAppVersion}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#MyAppURL}
AppSupportURL={#MyAppURL}
AppUpdatesURL={#MyAppURL}
Das obige sind natürlich nur Vorschläge. Nach dem nun bekannten Muster lassen sich leicht weitere Konstanten hinzufügen, zum Beispiel um die drei URLs auch wirklich unterschiedlich zu gestalten.
Mindestens eine weitere Information müssen wir noch angeben, und zwar den Ort, an dem die Installation erfolgen soll:
DefaultDirName={userpf}\{#MyAppName}
Diese heißt DefaultDirName, da das Verzeichnis während der Installation durch den User noch geändert werden kann. Die vordefinierte Konstante {userpf} wird von InnoSetup erst bei der Installation ausgewertet.
Es handelt sich um das benutzerspezifische Programm-Verzeichnis C:\Users\USERNAME\AppData\Local\Programs\ (siehe auch im Beitrag Setup für Access-Anwendungen, www.access-im-unternehmen.de/1316 unter Wohin mit dem Frontend).
In diesem Zusammenhang wird auch noch eine weitere Frage wichtig: Welche Rechte benötigt der User, der dieses Setup ausführen will
Bei “normalen” Setups ist es üblich und auch notwendig, dass man Admin-Berechtigungen hat. Wenn wir aber unsere Applikation wirklich nur im userspezifischen Teil der Festplatte installieren wollen, ist das nicht notwendig, dann genügen die Rechte des Users völlig. Das teilen wir dem Setup-Script natürlich ebenfalls mit:
PrivilegesRequired=lowest
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
