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.
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.
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.