Die Stunde der Wahrheit

Irgendwann naht die Stunde der Wahrheit. Die Anwendung, die in der IDE tadellos funktioniert, soll auf die Menschheit «losgelassen» werden und muss sich dort behaupten, wo vielleicht nur die «nackte Laufzeit» unter einer unbekannten Windows-Version zur Verfügung steht. Damit der Entwickler nicht alle zur Ausführung benötigten Dateien einzeln zusammensuchen und in ein Auslieferungsverzeichnis kopieren muss, gibt es Installationsprogramme und Werkzeuge, mit denen diese Installationsprogramme komfortabel erstellt werden. Es muss aber nicht immer eines der relativ kostspieligen Profi-Werkzeuge sein, häufig kommt man bereits mit den Bordmitteln von Visual Studio 2005 bestens aus.

In der Theorie verspricht .NET zwar ein XCopy-Deployment, bei der lediglich die zur Ausführung benötigten Assemblies in ein Verzeichnis auf dem Zielsystem kopiert werden müssen, doch sobald etwas mehr Komfort für den Anwender gewünscht wird und zum Beispiel Einträge im Startmenü erscheinen sollen, zusätzliche Ordner und Registry-Einträge angelegt werden müssen, reicht dieses Verfahren nicht mehr aus. Wer ein Setup-Programm benötigt, das diese und weitere Aufgaben übernehmen kann, muss sich leider mit der relativ uneinladend wirkenden Materie der Setup-Programme beschäftigen. Doch nach den ersten Gehversuchen stellt sich heraus, dass auch dieses Terrain begehbar ist und man für normale Anforderungen die Standardeinstellungen übernehmen kann.

Für das Anfertigen eines Setup-Programms bietet Visual Studio die Setup-Projekte. Ein Setup-Projekt ist ein eigenständiges Projekt, das in der IDE nachträglich zu einem Projekt hinzugefügt wird. Bei Setup-Projekten gibt es nichts zum Programmieren, alle Einstellungen werden in speziellen Editor-Fenstern getroffen, die zwar nicht gerade durch eine intuitive Benutzerführung glänzen, aber alle wichtigen Einstellungen bieten. Beim Kompilieren des Setup-Projekts entsteht eine Windows Installer-Datei (Erweiterung .Msi), die alle für die Installation benötigten Dateien enthält (mit Ausnahme der .NET-Laufzeit und anderer externer Abhängigkeiten) und an den Anwender ausgeliefert wird, der die Installer-Datei startet, um die Anwendung zu installieren. Zwei Tipps dazu: Erstens sollte das Setup-Projekt am Ende im Release-Modus kompiliert werden. Zweitens lässt sich im Eigenschaftenfenster des Projekts (nicht in den Eigenschaften) unter anderem auch der Produktname einstellen, der später im Startmenü erscheint.

Der Umgang mit dem Setup-Editor ist gewöhnungsbedürftig, da es keinen Assistenten gibt, der den Entwickler durch alle Schritte führt. Alle erforderlichen Einstellungen werden in den insgesamt sechs Editor-Fenstern eingestellt, die über Ansicht, Editor aufgerufen werden: Dateisystem, Registry, Dateitypen, Benutzeroberfläche, Benutzerdefinierte Aktionen und Startbedingungen. Eine kleine Verständnishürde könnte der Umstand sein, dass die Editoren stets das Zielsystem darstellen und nicht die Verhältnisse auf dem Rechner, auf dem das Setup-Projekt erstellt wird. Der Anwendungsordner ist daher jener Ordner, in dem die Anwendung auf dem Zielsystem installiert wird, der Desktop ist der Desktop des Zielsystems, die Registry ist die Registry auf dem Zielsystem und so weiter. Soll eine Datei zum Anwendungsordner hinzugefügt werden, muss diese auch im Setup-Projekt enthalten sein, denn ansonsten steht sie, während das Setup-Programm später ausführt, nicht zur Verfügung.

Am Anfang dreht sich fast alles um den Dateisystem-Editor, denn mit seiner Hilfe wird die Verzeichnisstruktur mit ihren Inhalten zusammengestellt, die auf dem Zielsystem bei der Installation angelegt werden soll. Am Anfang umfasst das Dateisystem nur die wichtigsten Bestandteile - Anwendungsordner, Desktop und Programmmenü. Weitere Verzeichnisse lassen sich über das Anklicken von Dateisystem mit der rechten Maustaste und Auswahl von Speziellen Ordner hinzufügen, so dass das Setup-Programm auch Dateien im Benutzerprofil anlegen oder die Assembly in den GAC installieren kann. Der wichtigste Begriff in diesem Zusammenhang ist die primäre Ausgabe. Sie steht für jene Assembly, die durch das zu installierende Projekt erzeugt wird. Soll die Assembly, was im Allgemeinen wünschenswert ist, über das Startmenü aufrufbar sein, muss zuerst eine Verknüpfung auf die primäre Ausgabe angelegt werden, die anschliessend auf den Eintrag im Programme-Menü gezogen und dort abgelegt und umbenannt wird - dieses Verhalten ist nicht gerade intuitiv - einen direkteren Weg scheint es nicht zu geben.

Den Reiz eines Setup-Programms machen individuelle Dialogfelder aus, die beispielsweise den Anwender zur Eingabe eines Lizenzschlüssels auffordern oder die obligatorischen Lizenzbedingungen anzeigen. Alles das lässt sich im Rahmen des Benutzeroberflächen-Editors zwar realisieren, es stehen aber nur vordefinierte Dialoge zur Verfügung, die nur einen geringen Spielraum für individuelle Erweiterungen lassen. Das Implementieren einer Ablauflogik erfolgt ausschliesslich über die Eigenschaften der einzelnen Bedienelemente, zu programmieren gibt es im Allgemeinen nichts. Eine zentrale Rolle spielt die Eigenschaft Condition vieler Dialogelemente, die für eine Bedingung steht, die sich indirekt aus dem Betätigen eines Auswahlelements eines vorher angezeigten Dialogs ergibt. Auf diese Weise lässt sich etwa erreichen, dass ein Ordner mit einem bestimmten Inhalt auf dem Zielsystem nur dann angelegt wird, wenn zuvor das entsprechende Bedienelement gewählt wurde. Eine Ausnahme sind Aktionen, die über Installer-Klassen gesteuert werden - hier gibt es die Möglichkeit, auf eine getätigte Eingabe zuzugreifen. Enthält ein Dialogfeld etwa eine Eingabebox «SerialNum», fragt der folgende Befehl ihren Inhalt ab:

Dim SerNum As String = Me.Context.Parameters.Item(«SerialNum»)

Soll das Setup-Projekt individuelle Aktionen ausführen, geschieht dies am einfachsten über eine Installer-Klasse, die als Projektvorlage angeboten wird. Ein Setup-Projekt kann eine beliebige Anzahl an Startbedingungen enthalten, die alle jeweils eine vordefinierte Bedingung prüfen und die Installation abbrechen, wenn diese nicht erfüllt ist. Es gibt zwei Sorten von Startbedingungen: Erstens die Suche nach einer Datei, einem Registry-Eintrag oder einer Installer-Komponente auf dem Zielsystem. Zweitens eine Startbedingung, die über ihre Condition-Eigenschaft eine Bedingung über eine vordefinierte Installer-Eigenschaft prüft und immer True oder False zurückgibt. Soll die Installation nur fortgesetzt werden, wenn mindestens Windows 2000 vorhanden ist, muss die Bedingung «VersionNT>=500» lauten. Wird eine bestimmte Menge an Arbeitsspeicher vorausgesetzt, lautet die Bedingung «PhysicalMemory>=1000000000». Von Anfang an eingebaut ist eine Startbedingung, die das Vorhandensein der .NET Laufzeit 2.0 abfragt. Alle diese Dinge wirken am Anfang ein wenig speziell, werden aber in der Dokumentation ausreichend beschrieben.

Bootstrapping bedeutet, dass ein Installationsprogramm jene Komponenten installiert, die für die Ausführung der Anwendung vorhanden sein müssen. Bei einer .NET-Anwendung ist dies in jedem Fall die .NET-Laufzeit. Darüber hinaus können es zusätzliche Programme sein, wie zum Beispiel der Internet Explorer 6.0 oder die MDAC 2.8, wenn die Anwendung unter Windows 2000 installiert wird, wo diese Komponenten unter Umständen nicht vorhanden sind. Bei VS.NET 2003 wurde noch ein externes in C++ geschriebenes Programm benötigt, welches in eine Setup.exe kompiliert wurde, die, gesteuert über eine Ini-Datei, dafür sorgte, dass zuerst die .NET-Laufzeit und anschliessend die Anwendung installiert wurde. Bei VS 2005 wird dies alles komfortabel in der IDE in den Eigenschaften des Setup-Projekts unter Veröffentlichen, Erforderliche Komponenten eingestellt. Das Ergebnis ist eine Setup.exe, die vor der Installation der Anwendung die erforderlichen Komponenten entweder aus einem lokalen Verzeichnis oder von einer angegebenen Webseite herunterlädt und installiert.

Seit Version 2.0 bietet das NET Framework mit ClickOnce eine interessante Alternative, die aber Installer-Dateien nur ergänzt und nicht überflüssig macht. Bei ClickOnce werden die zur Installation erforderlichen Dateien in ein Netzwerkverzeichnis kopiert. Dort stehen sie jedem Anwender im Netzwerk zur Verfügung. Der Entwickler kann einstellen, ob die Installation regulär, unter anderem mit Eintrag im Startmenü, oder nur temporär erfolgen soll, so dass auf dem Zielsystem nach Beendigung keine Spuren verbleiben. Ferner kann eine «Sicherheits-Sandbox» eingerichtet werden, so dass die Anwendung mit Partial Trust-Einstellungen ausgeführt wird und nicht auf das lokale Dateisystem zugreifen darf. ClickOnce wird bei VS 2005 über Erstellen, Veröffentlichen aktiviert und im Register Veröffentlichen der Projekteigenschaften konfiguriert. Es bietet sich als eine deutlich einfachere Variante zu Installer basierten Installation immer dann an, wenn eine typische SmartClient-Unternehmensanwendung, die ihre Daten über das Netz bezieht, im Unternehmensnetzwerk verteilt werden soll.