Als kleine Erweiterung behalten wir uns dann noch Folgendes vor:<\/p>\n
- \n
- Zu Beginn Darstellung von Betahinweis oder der Lizenzbedingungen, Bestätigung anfordern<\/li>\n
- Zu Beginn Darstellung im Stile „Was ist neu in diesem Release“<\/li>\n
- Abschließend eine Readme-Datei anzeigen<\/li>\n<\/ul>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Die .exe<\/b>-Datei würde ich dabei von der Verwaltung ausnehmen (Git: *.exe<\/b> in die .gitignore<\/b>-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.<\/p>\n
Grundprinzip des Setup-Scripts<\/h2>\n
Das Setup-Script ähnelt in weiten Bereichen streng genommen mehr einer .ini<\/b>-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<\/b>-Datei) zusammenbaut. Ausgeliefert wird dann nur diese .exe<\/b>-Datei.<\/p>\n
Wie bei einer .ini<\/b>-Datei üblich haben wir Sektionen mit Überschriften in eckigen Klammern wie zum Beispiel [Setup] <\/b>gleich zu Beginn.<\/p>\n
Innerhalb dieser Sektionen stehen dann zahlreiche Key-Value-Einträge im Format Key = Value<\/b>.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Zu Beginn definieren wir in der Sektion [Setup] <\/b>den Namen des zu installierenden Programms und einige weitere organisatorische Dinge:<\/p>\n
[Setup]\r\nAppId=TestSetup \r\nAppName=My Awesome AccessApp\r\nAppVersion=1.0.0\r\nAppVerName=AccessApp v1.0.0\r\nAppPublisher=Vorname Name\r\nAppPublisherURL=https:\/\/www.meine-homepage.de\r\nAppSupportURL=https:\/\/www.meine-homepage.de\r\nAppUpdatesURL=https:\/\/www.meine-homepage.de<\/pre>\n
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 <\/b>hat dabei eine Sonderstellung, denn diese Information wird in der Registry als Bezeichnung für den Uninstall<\/b>-Bereich eingetragen (siehe Bild 1). Hier finden Sie detaillierte Informationen über die Deinstallation.<\/p>\n
![\"Setup-Eintrag](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_001.png\")
<\/p>\nBild 1: Setup-Eintrag in der Registry<\/span><\/b><\/p>\n
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!<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Konstanten im Setup-Script<\/h2>\n
Die Definition der Konstanten erfolgt dabei zwingend am Anfang des Script vor der [Setup]<\/b>-Sektion nach folgendem Muster:<\/p>\n
#define MyAppName \"My Awesome AccessApp\"\r\n#define MyAppVersion \"1.0.0\"\r\n#define MyAppPublisher \"Christoph Jüngling\"\r\n#define MyAppURL \"https:\/\/www.meine-homepage.de\"\r\n#define MyAppExeName \"Testdatenbank.accdb\"<\/pre>\n
Nun können wir das obige Script entsprechend überarbeiten. Dabei werden die Konstanten nach dem Muster {#NameDerKonstante} <\/b>an der Stelle eingefügt, wo deren Wert stehen soll.<\/p>\n
[Setup]\r\nAppId={#MyAppName} \r\nAppName={#MyAppName}\r\nAppVersion={#MyAppVersion}\r\nAppVerName={#MyAppName} v{#MyAppVersion}\r\nAppPublisher={#MyAppPublisher}\r\nAppPublisherURL={#MyAppURL}\r\nAppSupportURL={#MyAppURL}\r\nAppUpdatesURL={#MyAppURL}<\/pre>\nDas 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.<\/p>\n
Mindestens eine weitere Information müssen wir noch angeben, und zwar den Ort, an dem die Installation erfolgen soll:<\/p>\n
DefaultDirName={userpf}\\{#MyAppName}<\/pre>\nDiese heißt DefaultDirName<\/b>, da das Verzeichnis während der Installation durch den User noch geändert werden kann. Die vordefinierte Konstante {userpf} <\/b>wird von InnoSetup erst bei der Installation ausgewertet.<\/p>\n
Es handelt sich um das benutzerspezifische Programm-Verzeichnis C:\\Users\\USERNAME\\AppData\\Local\\Programs\\ <\/b>(siehe auch im Beitrag Setup für Access-Anwendungen<\/b>, www.access-im-unternehmen.de\/1316 <\/b>unter Wohin mit dem Frontend<\/b>).<\/p>\n
In diesem Zusammenhang wird auch noch eine weitere Frage wichtig: Welche Rechte benötigt der User, der dieses Setup ausführen will<\/p>\n
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:<\/p>\n
PrivilegesRequired=lowest<\/pre>\n
<\/p>\n
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 <\/b>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).<\/p>\n
![\"Weitgehend](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_002.png\")
<\/p>\nBild 2: Weitgehend leeres Installationsverzeichnis<\/span><\/b><\/p>\n
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<\/b> einen passenden Eintrag zu unserer Installation (siehe Bild 3).<\/p>\n
![\"Eintrag](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_003.png\")
<\/p>\nBild 3: Eintrag in der Systemsteuerung<\/span><\/b><\/p>\n
Den Button Deinstallieren<\/b> sollten Sie zum Kennenlernen ruhig betätigen, und vergewissern Sie sich bitte anschließend, dass das Installationsverzeichnis wieder vollständig verschwunden ist.<\/p>\n
Nun haben wir herausgefunden, dass das Setup grundsätzlich funktioniert. Jetzt wollen wir die Access-Datenbank hinzufügen.<\/p>\n
Was und wohin installieren<\/h2>\n
Für diese Frage ist die Sektion [Files] <\/b>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:<\/p>\n
key1: value1; key2: value2; key3: value3; ...<\/pre>\n
Anstelle des tatsächlichen Dateinamens unserer Access-Datenbankapplikation verwenden wir die oben bereits definierte Konstante:<\/p>\n
[Files]\r\nSource: \"{#MyAppExeName}\"; DestDir: \"{app}\"; Flags: ignoreversion<\/pre>\nDas ist auch nicht schwierig zu verstehen, Source<\/b> und DestDir<\/b> (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<\/b> befindet!<\/p>\n
Zusätzlich wollen wir noch eine Readme<\/b>-Datei hinzufügen. Diese soll am Ende des Setups automatisch angezeigt werden.<\/p>\n
Dafür kommt eine weitere Zeile in diese Sektion, die ähnlich aussieht (jede Zeile beschreibt eine Datei):<\/p>\n
Source: \"readme.txt\"; DestDir: \"{app}\"; Flags: isreadme<\/pre>\nHierbei ist das Flag isreadme<\/b> interessant, denn es erzeugt auf der letzten Seite des Setup-Fensters automatisch eine Checkbox für die Anzeige (siehe Bild 4).<\/p>\n
![\"Readme-Datei](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_004.png\")
<\/p>\nBild 4: Readme-Datei anzeigen<\/span><\/b><\/p>\n
Die Angabe {app} <\/b>als Zielverzeichnis referenziert einfach das Installationsverzeichnis, das wie oben beschrieben vor oder während der Installation festgelegt wurde.<\/p>\n
Dieser Eintrag berücksichtigt also auch das, was der User eventuell verändert hat.<\/p>\n
Das Flag ignoreversion<\/b> ist sinnvoll, da die Access-Datenbank keine standardisierte Versionsnummer hat wie eine .exe<\/b>-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.<\/p>\n
Mehr muss in der Sektion [Files] <\/b>in diesem Beispiel nicht stehen.<\/p>\n
Wer will, kann das Setup nun erneut kompillieren und ausführen. Danach sollte zusätzlich die .accdb<\/b>-Datei und die Datei readme.txt <\/b>im Installationsverzeichnis enthalten sein.<\/p>\n
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]<\/b>.<\/p>\n
Auch hierbei gilt, dass für jedes Icon eine Zeile im Setup-Script benötigt wird. Die im Artikel eventuell dargestellten Zeilenumbrüche müssen Sie sich also bitte wegdenken.<\/p>\n
[Icons]\r\nName: \"{group}\\{#MyAppName}\"; Filename: \"{app}\\{#MyAppExeName}\"; WorkingDir: \"{app}\"; Flags: useapppaths\r\nName: \"{userdesktop}\\{#MyAppName}\"; Filename: \"{app}\\{#MyAppExeName}\"; WorkingDir: \"{app}\"; Flags: useapppaths<\/pre>\nDer erste Eintrag sorgt für das Icon im Startmenü (siehe Bild 5). <\/p>\n
![\"Eintrag](\"..\/fileadmin\/_temp_\/2021_05\/startmenue.png\")
<\/p>\nBild 5: Eintrag im Startmenü<\/span><\/b><\/p>\n
Der zweite liefert das Desktop-Icon (siehe Bild 6). In beiden wird die .accdb<\/b>-Datei aus dem Installationsverzeichnis gestartet. Dieser Ort wird wieder über den Platzhalter {app}<\/b> referenziert, der ebenfalls für den Eintrag Working Directory<\/b> verwendet wird.<\/p>\n
![\"Desktop-Verknüpfung](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_008.png\")
<\/p>\nBild 6: Desktop-Verknüpfung <\/span><\/b><\/p>\n
Das Flag useapppaths<\/b> weist Windows an, automatisch das mit .accdb <\/b>verknüpfte Programm aufzurufen. Dadurch sparen wir es uns, den Installationsort von MS Access herausfinden zu müssen und die Kommandozeile zusammenzusetzen.<\/p>\n
Damit die Referenz {group} <\/b>vernünftig benannt wird, fügen wir oben bei den Anfangsdefinitionen noch den entsprechenden Eintrag hinzu:<\/p>\n
DefaultGroupName={#MyAppName}<\/pre>\nDer Eintrag {group} <\/b>berücksichtigt übrigens automatisch die Unterscheidung zwischen globalem und benutzerspezifischem Eintrag. Bei dem Desktop-Icon müssen wir das per Konstante selbst tun (es gibt auch {commondesktop}<\/b>).<\/p>\n
Jetzt wird die Startmenü-Untergruppe genau so heißen wie unser Programm. Das muss natürlich nicht so sein, Sie können also jederzeit eine neue Bezeichnung festlegen.<\/p>\n
Sprache<\/h2>\n
Vielleicht ist Ihnen bereits aufgefallen, dass das Setup bisher englisch mit uns gesprochen hat. Das ist die Voreinstellung, aber das muss nicht so bleiben, daher wollen wir das noch schnell ändern. Es macht doch einen besseren Eindruck, wenn der Anwender in der für ihn üblichen Sprache begrüßt wird. Dafür ist die Sektion [Languages] <\/b>zuständig.<\/p>\n
Um Deutsch <\/b>hinzuzufügen, würde die entsprechende Zeile bereits ausreichen. Falls Sie Ihr Programm allerdings weltweit vertreiben wollen, sollte englisch zumindest als Auswahl ebenfalls dabei stehen. Bei Bedarf können Sie weitere vordefinierte Sprachen hinzufügen:<\/p>\n
[Languages]\r\nName: \"EN\"; MessagesFile: \"compiler:Default.isl\"\r\nName: \"DE\"; MessagesFile: \"compiler:Languages\\German.isl\"\r\nName: \"NO\"; MessagesFile: \"compiler:Languages\\Norwegian.isl\"\r\nName: \"FR\"; MessagesFile: \"compiler:Languages\\French.isl\"<\/pre>\n
Für die automatische Erkennung der Sprache bei der Installation ist der Eintrag ShowLanguageDialog <\/b>in der [Setup]<\/b>-Sektion zu empfehlen, denn hierbei gibt es eine Reihe von versteckten Automatiken, die sehr hilfreich sind.<\/p>\n
Zunächst wird die in Windows eingestellte Sprache für die Oberfläche ermittelt. Wenn diese in der obigen Liste der für das Setup vorgesehenen Sprachen vorhanden ist, wird diese automatisch ausgewählt. Durch den Eintrag ShowLanguageDialog=auto <\/b>wird in dem Fall gar nicht erst die Frage nach der Sprache gestellt.<\/p>\n
Falls die Sprache jedoch im Setup nicht vorbereitet ist, wird der Sprachdialog (siehe Bild 7) aufgerufen.<\/p>\n
![\"Sprachauswahl\"](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_005.png\")
<\/p>\nBild 7: Sprachauswahl<\/span><\/b><\/p>\n
Dabei wird zunächst die Sprache verwendet, die in der obigen Liste als erstes steht, der Benutzer kann jedoch seine Wunschsprache aus der Dropdown-Liste auswählen. Jede Sprache wird dabei in genau jener Sprache selbst aufgeführt.<\/p>\n
Der Präfix compiler:<\/b> bei der Eintragung MessageFile<\/b> bezieht sich übrigens auf das Installationsverzeichnis von InnoSetup.<\/p>\n
Die in [Languages] <\/b>aufgeführten Sprachdateien werden automatisch in das Setup einbezogen, sie müssen also nicht zusätzlich in den [Files]<\/b>-Abschnitt integriert werden.<\/p>\n
An dieser Stelle können wir noch auf die eingangs erwähnten Erweiterungen eingehen.<\/p>\n
Um diese zusätzlichen Informationen in der korrekten Sprache anzuzeigen, fügen wir den Zeilen im [Languages]<\/b>-Abschnitt je nach Bedarf weitere Attribute hinzu:<\/p>\n
- \n
- LicenseFile<\/b><\/li>\n
- InfoBeforeFile<\/b><\/li>\n
- InfoAfterFile<\/b><\/li>\n<\/ul>\n
Beispiel (auch hier gilt wieder, dass pro Sprache eine Zeile zu verwenden ist):<\/p>\n
[Languages]\r\nName: \"EN\"; MessagesFile: \"compiler:Default.isl\"; LicenseFile: \"license-en.txt\"\r\nName: \"DE\"; MessagesFile: \"compiler:Languages\\German.isl\"; LicenseFile: \"license-de.txt\"<\/pre>\n
Die Benennung der Dateien für die Lizenz oder die Infos ist dabei willkürlich, da die Zuordnung zur Sprache mit Hilfe des entsprechenden Language<\/b>-Eintrags erfolgt. Es ist lediglich für uns Entwickler hilfreich, wenn die Sprache und der Verwendungszweck im Dateinamen enthalten ist.<\/p>\n
Die Dateien für diese drei Verwendungszwecke können in zwei verschiedenen Formaten vorliegen:<\/p>\n
- \n
- Plain Text (siehe Bild 8)<\/li>\n
![\"Lizenzvereinbarung](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_006.png\")
<\/p>\nBild 8: Lizenzvereinbarung im Plain Text<\/span><\/b><\/p>\n
- Rich Text Format (siehe Bild 9)<\/li>\n
![\"Lizenzvereinbarung](\"..\/fileadmin\/_temp_\/2021_05\/pic_1326_007.png\")
<\/p>\nBild 9: Lizenzvereinbarung in RTF<\/span><\/b><\/p>\n<\/ul>\n
Die Textdatei muss dabei ANSI-codiert sein, UTF8 wird nicht korrekt dargestellt!<\/p>\n
Während InfoBeforeFile <\/b>und InfoAfterFile <\/b>einfach nur dargestellt werden, gibt es bei LicenseFile <\/b>eine Besonderheit. Wie in den beiden Screenshots bereits zu erkennen ist, muss der Benutzer die Entscheidung treffen, die Lizenz entweder zu akzeptieren oder abzulehnen.<\/p>\n
Aber nur wenn der Benutzer sie akzeptiert, wird der Button Weiter<\/b> freigegeben. Der einzige Nachteil dieser Darstellung ist dann vielleicht, dass das Fenster nicht vergrößerbar ist.<\/p>\n
Ich verwende den Lizenz-Dialog in der Regel für einen speziellen Beta-Hinweis, den ich bei Bedarf ein- oder ausschalte. Auf eine einfache Möglichkeit, nur ein Setup-Script für BETA<\/b>– und FINAL<\/b>-Version zu erstellen, werden wir in einem weiteren Beitrag eingehen.<\/p>\n
Das Rechtekonzept<\/h2>\n
Kommen wir abschließend zu dem vielleicht größten Hindernis für unsere Access-Applikation. Denn wenn Sie slle Einstellungen sorgfältig durchgeführt haben, werden Sie sicher auch schon einmal versucht haben, Ihre Applikation zu starten. Hat das funktioniert Wahrscheinlich nicht.<\/p>\n
Wir haben im Verlauf unseres Setups bereits festgelegt, dass wir die Applikation im Userbereich installieren wollen und deshalb auf Admin-Berechtigungen verzichten können. Doch das betrifft nur die Durchführung des Setups selbst und hat mit der Applikation nichts zu tun. Access hat da nämlich auch noch ein Wörtchen mitzureden.<\/p>\n
Wir kennen ja (nicht nur) von Access seit einiger Zeit das Konzept der Vertrauenswürdigen Speicherorte<\/b>. Microsoft möchte damit verhindern, dass irgendeine Datei mit VBA-Code auf unsere Festplatte gelangt und ohne weitere Kontrolle ausgeführt wird. Leider funktioniert die Verwendung einer digitalen Signatur für die VBA-Makros in Access nicht.<\/p>\n
Die meisten Verzeichnisse unserer Platte werden wohl nicht vertrauenswürdig sein, und das ist auch gut so. Man könnte sich das theoretisch zwar so einrichten, aber empfehlenswert ist es nicht. Wie Sie sicher wissen, können Sie diese Einstellungen für Access-Applikationen in den Optionen einstellen.<\/p>\n
Dazu öffnen Sie den Optionen-Dialog mit dem Ribbon-Eintrag Datei|Optionen<\/b>, wechseln dort zum Bereich Trust Center<\/b>, klicken auf Einstellungen für das Trust Center <\/b>und fügen dann unter Vertrauenswürdige Speicherorte <\/b>das entsprechende Verzeichnis hinzu.<\/p>\n
Das ist sicher keine große Sache, und nachdem man das einmal gemacht hat, braucht man sich bei Updates auch nie wieder darum zu kümmern. Andererseits sind wir Entwickler, und einen gewissen Drang, auch dieses noch zu automatisieren, verspürt wohl ein jeder von uns. Der Auflösung dieses Knotens werden wir uns dann gemeinsam im dritten Teil dieser Beitragsreihe widmen.<\/p>\n
Zusammenfassung<\/h2>\n
Wir haben nun gemeinsam ein fast komplettes Setup-Script für eine Access-Applikation entwickelt. Der User wird in seiner Sprache angesprochen, hat ein Mitspracherecht bei der Frage nach dem Installationsort und bekommt Startmenü- und Desktop-Icon hinzu.<\/p>\n
Er musste unsere Lizenz akzeptieren und das Programm lässt sich wie üblich deinstallieren. Das Script ist durch die Konstanten auch dafür vorbereitet, mit einfachen Anpassungen für weitere Access-Applikationen verwendet zu werden.<\/p>\n
Im nächsten Teil werden wir uns dann der Automatisierung des Eintrags für die vertrauenswürdigen Speicherorte widmen und dabei einen kleinen Einblick in die Programmiermöglichkeiten von InnoSetup erhalten.<\/p>\n
Außerdem wird es noch einen Tipp geben, wie wir sicherstellen können, dass die Access-Applikation nicht läuft, wenn wir sie updaten wollen. Die einfache Unterscheidung zwischen Beta- und Final-Version wäre ebenfalls eine Möglichkeit. Und die digitale Signatur unserer .exe<\/b>-Datei ist dann noch das Sahnehäubchen auf dem Kuchen. Dann ist das Setup „rund“.<\/p>\n
Und dieser ganze Aufwand nur, um unsere User zufrieden zu stellen Ja, ich denke, das ist es wert.<\/p>\n
Downloads zu diesem Beitrag<\/h2>\n
Enthaltene Beispieldateien:<\/p>\n
license-de.rtf<\/p>\n
license-de.txt<\/p>\n
license-en.txt<\/p>\n
readme.txt<\/p>\n
setup.iss<\/p>\n
Testapplikation.accdb<\/p>\n
- Rich Text Format (siehe Bild 9)<\/li>\n
- InfoBeforeFile<\/b><\/li>\n
- LicenseFile<\/b><\/li>\n