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
Nun können Sie das Setup bereits kompilieren, obwohl im Moment natürlich noch gar nichts installiert wird. Zu diesem Zweck drücken Sie F9 in InnoSetup oder Inno Script Studio, lassen das Setup durchlaufen und schauen dann in das angegebene Verzeichnis. Dort finden wir im Moment nur zwei Dateien (siehe Bild 2).
Bild 2: Weitgehend leeres Installationsverzeichnis
Es handelt sich um den Uninstaller und die von ihm benötigte Daten-Datei. Zugleich finden wir in der Systemsteuerung unter Programme hinzufügen oder entfernen einen passenden Eintrag zu unserer Installation (siehe Bild 3).
Bild 3: Eintrag in der Systemsteuerung
Den Button Deinstallieren sollten Sie zum Kennenlernen ruhig betätigen, und vergewissern Sie sich bitte anschließend, dass das Installationsverzeichnis wieder vollständig verschwunden ist.
Nun haben wir herausgefunden, dass das Setup grundsätzlich funktioniert. Jetzt wollen wir die Access-Datenbank hinzufügen.
Was und wohin installieren
Für diese Frage ist die Sektion [Files] zuständig. Hier werden alle Dateien aufgeführt, die in das Setup eingepackt werden sollen. Das ist vorerst nicht viel in unserem Projekt. Die Syntax lautet in diesem Bereich etwas anders als zu Beginn besprochen, da hier mehrere Informationen pro Datei in einer Zeile erfasst werden:
key1: value1; key2: value2; key3: value3; ...
Anstelle des tatsächlichen Dateinamens unserer Access-Datenbankapplikation verwenden wir die oben bereits definierte Konstante:
[Files]
Source: "{#MyAppExeName}"; DestDir: "{app}"; Flags: ignoreversion
Das ist auch nicht schwierig zu verstehen, Source und DestDir (destination directory) erklären sich wohl selbst. Alle Pfadangaben sind hier übrigens relativ zu dem Verzeichnis zu verstehen, in dem sich das Setup-Skript mit der Dateiendung .iss befindet!
Zusätzlich wollen wir noch eine Readme-Datei hinzufügen. Diese soll am Ende des Setups automatisch angezeigt werden.
Dafür kommt eine weitere Zeile in diese Sektion, die ähnlich aussieht (jede Zeile beschreibt eine Datei):
Source: "readme.txt"; DestDir: "{app}"; Flags: isreadme
Hierbei ist das Flag isreadme interessant, denn es erzeugt auf der letzten Seite des Setup-Fensters automatisch eine Checkbox für die Anzeige (siehe Bild 4).
Bild 4: Readme-Datei anzeigen
Die Angabe {app} als Zielverzeichnis referenziert einfach das Installationsverzeichnis, das wie oben beschrieben vor oder während der Installation festgelegt wurde.
Dieser Eintrag berücksichtigt also auch das, was der User eventuell verändert hat.
Das Flag ignoreversion ist sinnvoll, da die Access-Datenbank keine standardisierte Versionsnummer hat wie eine .exe-Datei oder eine DLL. Diese würde InnoSetup automatisch auslesen und mit der eventuell schon existierenden Datei vergleichen, so dass nur eine neuere Version installiert wird. Das geht bei Access leider nicht, daher dieses Flag.
Mehr muss in der Sektion [Files] in diesem Beispiel nicht stehen.
Wer will, kann das Setup nun erneut kompillieren und ausführen. Danach sollte zusätzlich die .accdb-Datei und die Datei readme.txt im Installationsverzeichnis enthalten sein.
Nun kümmern wir uns noch um den Startmenüeintrag und die Desktop-Icons. Dafür benötigen wir wieder eine neue Sektion namens [Icons].
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo