Installer: MSI oder nicht

[mkinzler]

Zitat:

Du solltest auf jeden Fall etwas nehmen was für den Windows Installer gemacht ist.

Ich nehme immer etwas extra nicht MSI basierend, wie das erwähnte InnoSetup

Beiträge wurden aus diesem Thread ausgelagert

[Assarbad]

Zitat:

Zitat von mkinzler (Beitrag 1086832)

Zitat:

Du solltest auf jeden Fall etwas nehmen was für den Windows Installer gemacht ist.

Ich nehme immer etwas extra nicht MSI basierend, wie das erwähnte InnoSetup

Dann hast du keine Kunden die in riesigen IT-Umgebungen auf hunderten oder tausenden Rechnern die Software verwalten müssen ... :stupid: (ach ja, und du hast den Fortschritt verschlafen)

[mkinzler]

Nein, aber massive Probleme mit defakten Windows Installer Datenbanken

[sh17]

Zitat:

Zitat von Assarbad (Beitrag 1086848)

(ach ja, und du hast den Fortschritt verschlafen)

:roll: wer definiert jetzt "Fortschritt"

[Assarbad]

Zitat:

Zitat von mkinzler (Beitrag 1086855)

Nein, aber massive Probleme mit defakten Windows Installer Datenbanken

Hmm, dann spart ihr also auch noch am falschen Ende und signiert eure MSIs nicht (signtool kann nämlich auch das), nehme ich an? Es kommt noch besser, man kann seinen MSIs sogar einschärfen nur Patches mit einer bestimmten Signatur zu benutzen usw ...

Ernsthaft, wenn man sich mal mit MSI beschäftigt und von dem prozeduralen Ansatz aller anderen Setupmethoden weggeht, sieht man erstmal wie toll MSI eigentlich ist. Insbesondere mit Advertising und diversen Deployment-Features in AD-Umgebungen ...

Problem ist, die meisten machen sich keine Gedanken und benutzen sowas wie InstallAware, InstallShield oder WISE und wundern sich danach über allerlei Probleme.

[Lemmy]

hi,

mit Wix habe ich mich auch mal beschäftigt - als es mir dann scripte erzeugt hat, die für die Installation von Assemblies incl. COM-Server Registrierung zuständig waren, die dann allerdings die installierten Netzwerkgeräte und Netzwerkeinstellungen überschrieben hat, habe ich das Ding wieder aufgehängt... am höchsten Ast. Interessant an der GEschichte war noch: Mit Dotfuscateten Assemblies ließ sich das noch Monate danach (vermutlich auch noch heute) zuverlässig reproduzieren, die nicht Dotfuscateten Assemblies ließen sich ohne Probleme installieren. Die Teilscripte habe ich damals übrigens mit candle und light (so heißen die Programme wirklich) erstellt - also alles Wix-Internas und genau so wie es sich M$ vorstellt....

Mit Inno hatte ich nie Probleme. Selbst in Umgebungen, die automatisch SOftware im Netzwerk ausrollten (hatte ich alleridngs nur 2-3 mal in der Zeit...)

Grüße

[Assarbad]

Zitat:

Zitat von sh17 (Beitrag 1086866)

:roll: wer definiert jetzt "Fortschritt"

Gute Frage. War aber eher technisch gemeint. Denn MSI benötigt keinen Code in der Datei. Es handelt sich um eine Datenbank mit Tabellen in denen man sozusagen nur die vorgefertigten Aktionen ausfüllt. Wenn man mal selber Code drin braucht, sollte man eine Custom Action schreiben (geht als DLL, Skript oder EXE) und diese wird dann in geschützter Umgebung von Windows Installer aufgerufen. Der Vorteil gegenüber bspw. selbstregistrierenden COM-DLLs (die man schon seit Jahren nicht mehr verwenden soll) ist, daß durch die Vermeidung von Code in der Datei und Windows Installer als Systemkomponente immer garantiert ist, daß die MSI sauber entfernt werden kann. Wenn man die Aktion: "lege Registryschlüssel da an, befülle ihn mit diesen Werten" als Grundlage nimmt, dann kann diese höchst einfach wieder umgekehrt werden. Ähnliches machen ja auch die Setupsysteme bei denen eine .exe hinten rauskommt. Allerdings hat man bei diesen keine Unterstützung für Advertising, Komponenten und Patches wie bei MSI. Und bei MSI sind es alles nur Daten, sprich die Überprüfung findet statt bevor irgendwelcher Code ausgeführt wird. Eine Installation mit MSI ließe sich auch dann noch rückgängig machen wenn das Programm aus Kompatibilitätsgründen (siehe InstallShield) längst nicht mehr funktioniert.

Alle bei denen nicht sauber entfernt wird, welche ich bisher gesehen habe, wurden nicht sauber konzipiert. Sprich: der Autor konnte nicht aus seinen Denkmustern raus und stellte sich das Setup eher als Sequenz von Befehlen (eben ähnlich einem Programm) in der Setupdatei vor (was eben einfach mit MSI nicht mehr der Fall ist). Deswegen sind diese Monster von Setupsystemen wie InstallAware auch nicht wirklich besser, da sie mithilfe von CAs einfach den skriptbasierten Ansatz nachbauen und in eine MSI gießen. Vielfach sind dann diese Setups genauso fragil wie diverse .exe-basierte.

Wenn man als Admin einmal einen Rollout mit MSI gemacht hat und sich den Vergleich mit den zusammengeflickten Lösungen irgendwelcher .exe-basierten Setups anguckt, will man MSI nicht mehr missen. Und ja, ich halte das für Fortschritt.

Zitat:

Zitat von Lemmy (Beitrag 1086879)

mit Wix habe ich mich auch mal beschäftigt - als es mir dann scripte erzeugt hat, die für die Installation von Assemblies incl. COM-Server Registrierung zuständig waren, die dann allerdings die installierten Netzwerkgeräte und Netzwerkeinstellungen überschrieben hat, habe ich das Ding wieder aufgehängt... am höchsten Ast. Interessant an der GEschichte war noch: Mit Dotfuscateten Assemblies ließ sich das noch Monate danach (vermutlich auch noch heute) zuverlässig reproduzieren, die nicht Dotfuscateten Assemblies ließen sich ohne Probleme installieren. Die Teilscripte habe ich damals übrigens mit candle und light (so heißen die Programme wirklich) erstellt - also alles Wix-Internas und genau so wie es sich M$ vorstellt....

Dann wäre nur die Frage ob du eine Pre-Releaseversion benutzt hast. Denn viele haben schon die 3.5er benutzt bevor sie stabil war. Da muß man sich dann nicht wundern. Da bin ich lieber konservativ und dann klappt das. Aber damit will ich nicht deine negativen Erfahrungen infrage stellen. Es ist nur so, daß MSI nach wie vor verkannt wird, weil die meisten Leute einfach nicht begreifen (wollen?), daß es nicht eine Abfolge von Befehlen ist die in der Setupdatei festgelegt wird, sondern daß die Abfolge Teil des Windows Installer ist und man im Prinzip den vorgegebenen Sequenzen und Aktionen folgend nur noch die Daten einträgt. Keine Angst, ein tieferes Verständnis fehlte mir dazu bis vor etwa vier Jahren auch und trotz positiver Erfahrungen als Admin war ich MSI abgeneigt. Seit ich mich zum Thema schlaugelesen habe (es gibt ein dt. Buch zu Windows Installer allgemein von MS Press), habe ich eine andere Sicht der Dinge ...

Habe auch noch ein altes in WISE (WISE for Windows Installer) erzeugtes Projekt zu verwalten und finde es insgesamt grauenhaft. Mittlerweile habe ich es so durchgeskriptet (dank der Automation-Schnittstellen), daß nichts großartig mehr schiefgehen kann. Aber das ist doch kein Arbeiten, wenn das System nicht von Grund auf darauf ausgelegt ist automatisiert zu werden.

Allerdings kann man allen FLOSS-Systemen: NSIS und Inno und auch WiX zugutehalten, daß eben eine Textform gewählt wurde die jeweils leicht mit einer anderen Revision vergleichbar ist (Versionskontrolle). Die WISE-Projekte sind verkappte MSI-Datenbanken (auch wieder nicht richtig, aber es reicht um sie mit den entsprechenden Schnittstellen zu modifizieren) und damit Binärdateien. Sowas macht sich sehr schlecht beim Vergleich. XML ist da weitaus freundlicher, oder auch Inno/NSIS-Skripte.

Zitat:

Zitat von Lemmy (Beitrag 1086879)

Mit Inno hatte ich nie Probleme. Selbst in Umgebungen, die automatisch SOftware im Netzwerk ausrollten (hatte ich alleridngs nur 2-3 mal in der Zeit...)

Klar gibt es mittlerweile allerlei zusammengeschusterte Lösungen für die populären Setupsysteme (zu denen man Inno wohl durchaus zählen darf) - aber das Gelbe vom Ei sind die alle nicht gewesen. Es gab ja da Seiten wie unattended.sf.net die sich nur damit auseinandersetzten wie man diverse Setups automatisiert ... glücklicherweise muß ich Adminjobs nur noch höchst selten übernehmen.

[sh17]

@Assarbad

Ich möchte die Vorteile von MSI keinesfalls schlecht reden. Aber ich finde, man sollte doch immer den Kontext beachten, wo die zu installierende Software eingesetzt wird. Nur um eine Exe mit ein paar Daten zu installieren, brauch ich den ganzen Schotter nicht, da reicht InnoSetup, aber nur weil ich es dem Anwender einfacher machen möchte. Eigentlich würde schon eine ZIP reichen, aber... Alles andere wäre mit Kanonen auf Spatzen usw.

In den Genuss von automtischen Setups und sonstigen Feinheiten, werde ich nicht kommen (müssen).

Danke für die Aufklärung, was MSI alles kann. Recht interessant.

[sh17]

Zitat:

Zitat von himitsu (Beitrag 1086943)

Also, wenn ein Admin in seinem Netzwerk dein Programm freigeben will, muß er es eventuell auf jedem Rechner einzeln installieren?

Muss er nicht ;-)

[himitsu]

OK, deine Zip könnte er entpacken und schreibt sich dann ein Script, welches das überall hinkopiert. :stupid: