Ich hatte kürzlich mit einem Installationsprojekt zu kämpfen (das das beliebteste Produkt zur Erstellung von Installationen verwendet: InstallShield), damit es für Produkt-Upgrades funktioniert (Migration von einer Version zur anderen). Am Ende stellte sich heraus, dass ich einen langen Paketcode verwenden musste, aber einen anderen verwendete. Es verschwendet meine 8 Stunden (Testen und Debuggen von Installern ist ein Schmerz).
Wenn ich jetzt darüber nachdenke, sobald Sie den ganzen schwierigen Teil der Programmierung erledigt haben, wollen Sie nur die richtigen Anwendungen, Bibliotheken werden auf den Zielcomputer kopiert und der Benutzer führt sie einfach aus. Zeitraum. Diese scheinbar einfache Aufgabe stellt sich normalerweise als schwierig heraus, und "bis zum Abschlusstermin geschlossen zu sein" macht es noch schwieriger.
Glauben Sie nicht, dass die Bereitstellung eines Produkts unter Windows verdammt schwierig ist, was einfacher hätte sein sollen? (oder Installateur verdient wirklich viel Aufmerksamkeit und ich bin einfach verrückt danach?)
Haben Sie schon einmal einfachere Deployment-Schemata verwendet, z. B. "Kopieren Sie den Ordner dorthin, wo Sie möchten und führen Sie die Exe aus. Wenn Sie sie löschen möchten, löschen Sie einfach den Ordner!"? War es effektiv und machte die Dinge einfacher?
Schmerzhaft wie es ist, müssen Sie mit dem Windows-Installer zum Vorteil Ihrer Kunden ringen. Ansonsten müssen Sie viel mehr tun, um
zu arbeitenIhre eigenen benutzerdefinierten Skripte zur Lösung all dieser Probleme werden zu einem größeren Problem als die Installation selbst!
Ich empfehle, dass Sie sich Wix anschauen. Es ist nicht gerade ein Kinderspiel, aber es macht den Job erledigt. Wenn Sie Votive als Visual Studio installieren, fügen Sie intellisense hinzu, um die Tags korrekt zu strukturieren. Mit der Hilfedatei können Sie ziemlich funktionale flexible Installationen erstellen
Ich denke nicht, dass Sie hier zu viele Meinungsverschiedenheiten sehen werden, besonders in Bezug auf MSI. Ich denke, eine Sache zu beachten ist zu beobachten, wie viele Programme MSI-Dateien in diesen Tagen verwenden. Das Anzeigen von UI-Dialogen und das Ausführen komplexer Konfigurationsoptionen mit einem MSI ist aufgrund der Art und Weise, wie Windows Installer entwickelt wurde, sehr schwach. Daher habe ich festgestellt, dass viele Programme in eine Reihe von Baby-MSIs aufgeteilt werden, die mit der minimalen Benutzeroberfläche von a installiert werden Eltern-Setup-Programm. Der SQL Server 2008-Setup-Assistent führt dies aus. UPS WorldShip macht das. Und Paint.NET macht das auch - der Assistent, den Sie sehen, ist eine Windows Forms App und startet msiexec selbst (Sie können die minimale Benutzeroberfläche des Windows Installers oben auf dem weißen Fenster des Assistenten sehen) alle Konfigurationsparameter als Eigenschaftsargumente für msiexec .
Ein häufiges Szenario, in dem dies auftritt, ist, dass jemand damit beauftragt wird, ein Installationsprogramm für eine Anwendung zu erstellen, die sowohl Server- als auch Client-Gegenstücke hat. Wenn der Benutzer die Serveroption auswählt, möchte er möglicherweise eine neue Datenbank installieren oder nicht, was die Installation von SQL Server bedeutet. Sie können SQL Server nicht einfach installieren, während Sie sich gerade in der Mitte der eigenen Installation befinden, da Windows Installer dies nicht zulässt. Eine häufige Lösung besteht darin, eine App zu schreiben, die einen Assistenten anzeigt, mit dem der Benutzer alle Setup-Optionen konfigurieren kann. Anschließend startet die App die MSI-Dateien nach Bedarf für SQL Server, Ihre Serveranwendung und Ihre Clientanwendung UI-Modus; im Grunde, was den "Features" -Aspekt von Windows Installer gänzlich ausschließt und ihn auf die MSI-Ebene bringt. 4.5's Multiple-Package-Installationen scheinen einen Schritt weiter in diese Richtung zu gehen. Dieses Format ist auch besonders nützlich, wenn Sie auch Nicht-MSI-Installer von Drittanbietern als Teil Ihres Installationsprozesses einbinden müssen, wie z. B. das Installieren eines Druckertreibers für einen bizarren Point-of-Sale-Drucker.
Ich stimme auch zu, dass Windows Installer keine integrierte Unterstützung für allgemeine Bereitstellungsszenarien bietet. Es ist dafür gedacht, wenn Setup nicht XCOPY ist, aber sie scheinen die Tatsache zu verpassen, dass Setup normalerweise nicht nur "Dateien + Verknüpfungen + Registrierungsschlüssel" ist. Es gibt keine integrierten Aktionen zum Einrichten von IIS-Websites, zum Registrieren von Zertifikaten, zum Erstellen und Aktualisieren von Datenbanken, zum Hinzufügen von Assemblys zum GAC und so weiter. Ich nehme an, dass sie der Meinung sind, dass ein Teil davon beim ersten Start passieren sollte, anstatt ein transaktionaler Teil der Installation zu sein. Die frei verfügbaren Werkzeuge und Dokumentationen waren für den größten Teil eines Jahrzehnts furchtbar - völlig entsetzlich. Beide Probleme werden im Wesentlichen durch das WiX-Projekt und DTF (mit dem Sie schließlich benutzerdefinierte Code-Aktionen verwalten können) angesprochen. Deshalb sind wir alle so dankbar für die Arbeit von Rob Mensching und anderen an diesem Projekt.
Ich habe die gleiche Erfahrung gemacht. Die Installation kann schnell Ihre Zeit verschlingen, wenn Sie das Kaninchenloch von "Oh Gott, ich glaube, ich muss auch Experte in this werden." Ich stimme der Idee zu, dass es am besten ist, sie frühzeitig in Ihrem Projekt anzugehen und sie als Teil Ihres Build-Prozesses beizubehalten. Auf diese Weise können Sie das Szenario vermeiden, dass Sie ein praktisch nicht installierbares Produkt entwickelt haben. (Trac war für eine Weile ein Beispiel dafür, bestimmte Versionen von seltsamen Python-Bibliotheken ausfindig zu machen.)
(Ich könnte darüber reden, dass Windows Installer manchmal beschließt, meine langsame, externe USB-Festplatte als einen Ort zu benutzen, um seine Dateien zu dekomprimieren, wie es dort zu sitzen scheint und minutenlang nichts tut auf Computern, die viel davon hatten MSI installiert auf ihnen, und wie dieser Fortschrittsbalken eine Bazillion Mal während einer einzigen Installation zurückgesetzt ist das idiotischste, was ich je gesehen habe, aber ich werde diese Schimpfwörter für einen anderen Tag speichern. =)
Meine zwei Cent; Bitte beachten Sie, dass ich wirklich nur genug über Windows Installer weiß, um Schaden anzurichten, aber das ist meine Einschätzung, die von einem kleinen Geschäftsentwickler kommt, der gerade versucht, es zu benutzen. Viel Glück!
Nun, es ist viel einfacher, wenn Sie zuerst Ihr Installationsprogramm erstellen, es Teil Ihres Build-Systems machen und es mit Ihrem Projekt wachsen lassen.
Ich stimme zu, der Windows Installer macht mich wahnsinnig. Aber es gibt viele Situationen, die xcopy nicht löst. Manchmal möchten Sie für mehrere Benutzer installieren, nicht nur den aktuellen Benutzer. Manchmal müssen Sie COM-Objekte registrieren. Manchmal müssen Sie eine Reihe von Änderungen am System vornehmen, z. B. die Registrierung von Diensten beim Start, die Verbindung mit Netzwerkservern usw. Manchmal haben Sie Benutzer, die keine Eingabeaufforderung verwenden können. Und du willst immer das ganze Ding zurückrollen können, wenn etwas auf halbem Wege scheitert.
War die gesamte MSI-Datenbank der beste Weg, dies zu tun? Ich bin mir nicht sicher. Würde ich lieber Nägel in den Kopf schlagen, als eine weitere Zeile WiX-Code zu schreiben? Wahrscheinlich. Aber Sie müssen zugeben, es macht einen guten Job, alles zu tun, was Sie jemals wollen könnten. Und wenn dies nicht der Fall ist, gibt es immer die Option CustomAction.
Wirklich, was ich gerne sehen würde, ist eine bessere Dokumentation (wirklich, was ist eine Aktion vom Typ 50? Wie wäre es mit einem Namen?) und eine Menge einfacher zu nutzender Vorlagen.
Und der Alias der WiX-Benutzergruppe kann Fragen gut beantworten.
Sie sollten RobMens Blog lesen . Er macht einen guten Job und erklärt, warum die Dinge so sind, wie sie sind. Er hat viel über die Probleme des Setups nachgedacht (mehr als jeder Mensch).
Persönlich stimme ich größtenteils @Conrad und @John Saunders zu. Ich schrieb über dieses Thema vor langer Zeit auf meinem alten Blog . Ich denke, @jeffamaphone einen Punkt über die Windows Installer Komplexität hat (und meine über die Aufmerksamkeit auf Setup im Allgemeinen), aber ich glaube, dass die Windows Installer ist immer noch die beste Allround-Option für die Installation unter Windows.
"Sobald Sie den ganzen schwierigen Teil der Programmierung gemacht haben", haben Sie nichts getan, wenn Ihre ganze harte Arbeit nicht installiert wird. Installateure müssen jeden Abend gebaut und getestet werden, jeden Abend, fast vom ersten Tag an. Sie müssen testen, ob das Installationsprogramm erstellt und ausgeführt werden kann, und Sie müssen die Installation überprüfen.
Anderenfalls, wen interessiert wie viel harte Arbeit Sie mit der Programmierung gemacht haben - niemand wird Ihre Arbeit jemals sehen, wenn sie nicht installiert wird!
Beachten Sie, dass dies auch für XCOPY gilt.
Eine andere Sache: Was ist Ihr QA-Test, wenn Sie nicht testen, was Ihr Installer installiert? Sie müssen testen, was der Kunde bekommt!
Genau aus den von Ihnen genannten Gründen haben wir interne Releases durchgeführt, die vom Entwicklerteam durch Kopieren der erforderlichen Dateien erledigt wurden, und dann den Rest des Setups mithilfe von Skripten und unseren eigenen Dienstprogrammen erledigt.
Aber für Endbenutzer müssen Sie einen Assistenten für die Hand halten, ich habe das MS-Installationsprogramm von VS verwendet und fand es verwirrend und klobig. Nach dieser Erfahrung habe ich den Schmerz vermieden, indem ich andere dazu gebracht habe, den Installationsschritt zu machen. Kann jemand ein gutes .Net Installationsprogramm empfehlen?
Ich benutze Installshield und wenn Sie nicht versuchen etwas zu ausgefallenes zu machen (ich wieso sollten Sie) dann ist es ziemlich geradlinig - setzen Sie die Grundeinstellung, wählen Sie Dateien, richten Sie Verknüpfungen ein und erstellen Sie setup.exe.
Alle zukünftigen Updates, die ich in meinem Code behandle - viel bequemer für den Benutzer