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:

[Lemmy]

Guten morgen,

Zitat:

Zitat von Assarbad (Beitrag 1086903)

Dann wäre nur die Frage ob du eine Pre-Releaseversion benutzt hast.

so habe mir die Zeit genommen die 3.5er runter zu laden. Es scheint, dass ich damals die Wix 2.0er hatte, da seit der V 3 das von mir verwendete tallow (um aus den Assemblies automatisch scripte zu erzeugen) in "heat" aufgegangen ist. Ob das damals eine Pre-Version war (war 2008 und dann habe ich das 2009 nochmal versucht) kann ich nicht mehr sagen.

Also habe ich das mal mit heat versucht und schau mal was der da ausspuckt:

!! BITTE DIESE KEYS NICHT INSTALLIEREN ODER IN DIE REGISTRY KOPIEREN !!

Code:

<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="EnableFileTracing" Value="0" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="EnableConsoleTracing" Value="0" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="FileTracingMask" Value="-65536" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="ConsoleTracingMask" Value="-65536" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="MaxFileSize" Value="1048576" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing\RASAPI32" Name="FileDirectory" Value="C:\windows\tracing" Type="string" Action="write" />
<RegistryValue Root="HKLM" Key="Software\Microsoft\Tracing" Name="EnableConsoleTracing" Value="0" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\Winmm" Name="wheel" Value="1" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5\Catalog_Entries" Value="" Type="string" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5" Name="Num_Catalog_Entries" Value="0" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5" Name="Serial_Access_Num" Value="1" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9\Catalog_Entries" Value="" Type="string" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9" Name="Num_Catalog_Entries" Value="0" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9" Name="Next_Catalog_Entry_ID" Value="1001" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9" Name="Serial_Access_Num" Value="1" Type="integer" Action="write" />
<RegistryValue Root="HKLM" Key="System\CurrentControlSet\Services\WinSock2\Parameters" Name="WinSock_Registry_Version" Value="2.0" Type="string" Action="write" />

Die Assembly um die es hier geht ist ein winzig kleiner Bestandteil einer größeren Sammlung von Assemblies, die zusammen einen Rechenkern darstellen. die einzige kritische Komponente in den Assemblies ist der Zugriff auf eine Datenbank über MDAC - ansonsten keinerlei System- oder Netzwerkzugriffe die die Registry-Keys oben begründen.

Klar könnte ich hergehen und die ca. 10.000 Zeilen Script nach "HKLM" durchsuchen - aber ich weiß ehrlich gesagt immer noch nicht was WIX da eigentlich macht und ob noch wo anders weitere solche Hämmer versteckt sind. Sicherlich ist auch die Aufgabe jetzt nicht mehr soo alltäglich und ich weiß dass WIX<>MSI ist. Dennoch das Zeug stammt aus der selben Feder, das macht mich schon nachdenklich ;-)


Grüße

[generic]

Auf die Patch-Erzeugung für MSI wurde hier noch nicht eingegangen. Das ist eine prima Sache. Man baut sich zwei Setups und vergleicht die mit einen Diff-Tool. Die Differenz wird dann in eine MSP abgelegt, welche natürlich nur noch die Änderungen enthält.

Die MSP lässt sich dann verteilen bzw. über das alte Setup installieren.
u.a. nutze Adobe MSPs um den Acrobat Reader aktuell zu halten.

Wie es genau geht, habe ich im Entwickler erklärt.
Ich glaube es war in Teil 3 oder 4.

• Entwickler Magazin (Ausgabe: 03.09/15.04.2009) Artikel: MSI-Pakete mit Open-Souce-Software erzeugen Teil 4
• Entwickler Magazin (Ausgabe: 02.09/12.02.2009) Artikel: MSI-Pakete mit Open-Souce-Software erzeugen Teil 3
• Entwickler Magazin (Ausgabe: 01.09/10.12.2008) Artikel: MSI-Pakete mit Open-Souce-Software erzeugen Teil 2
• Entwickler Magazin (Ausgabe: 06.08/15.10.2008) Artikel: MSI-Pakete mit Open-Souce-Software erzeugen

Assarbad steht du neuerdings auf meiner Gehaltsliste?
Schön das du den WI so unterstützt.
;-)

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1086953)

so habe mir die Zeit genommen die 3.5er runter zu laden. Es scheint, dass ich damals die Wix 2.0er hatte, da seit der V 3 das von mir verwendete tallow (um aus den Assemblies automatisch scripte zu erzeugen) in "heat" aufgegangen ist.

Alles klar. Mit tallow hatte ich damals auch Probleme. Jetzt weiß ich worauf du hinaus wolltest. Habe es dann immer händisch gemacht, was so schwer nicht ist, wenn man die .rgs ohnehin hat. Wobei natürlich mit steigender Anzahl der Klassen und anderer Infos auch der Aufwand unbotmäßig steigt, wenn man es nicht wenigstens ein wenig skriptet.

Zitat:

Zitat von Lemmy (Beitrag 1086953)

Klar könnte ich hergehen und die ca. 10.000 Zeilen Script nach "HKLM" durchsuchen - aber ich weiß ehrlich gesagt immer noch nicht was WIX da eigentlich macht und ob noch wo anders weitere solche Hämmer versteckt sind.

Kann ich nachvollziehen. Schade, daß du in dieser Hinsicht schlechte Erfahrungen gemacht hast.

Zitat:

Zitat von Lemmy (Beitrag 1086953)

Sicherlich ist auch die Aufgabe jetzt nicht mehr soo alltäglich und ich weiß dass WIX<>MSI ist. Dennoch das Zeug stammt aus der selben Feder, das macht mich schon nachdenklich ;-)

Meines Wissens nach wurde WiX von einem aus dem MSO-Team initiiert. Aus der gleichen Feder stimmt also so nicht, auch wenn es beides unter der Ägide von MS produziert wird.

Zitat:

Zitat von generic (Beitrag 1086959)

Auf die Patch-Erzeugung für MSI wurde hier noch nicht eingegangen. Das ist eine prima Sache. Man baut sich zwei Setups und vergleicht die mit einen Diff-Tool. Die Differenz wird dann in eine MSP abgelegt, welche natürlich nur noch die Änderungen enthält.

Jupp, man kann das sogar noch feintunen in den PCPs. Mit WiX braucht man nichtmal mehr die MSIs, denn die Differenz kann auch mit .wixpdb ermittelt werden - geht schneller und ist präziser.

Zitat:

Zitat von generic (Beitrag 1086959)

Assarbad steht du neuerdings auf meiner Gehaltsliste?

Muß ich mal auf dem Konto und im Briefkasten nachgucken.

Zitat:

Zitat von generic (Beitrag 1086959)

Schön das du den WI so unterstützt.
;-)

Ich habe einfach das Gefühl, daß bei MSI vielfach das Problem ist, daß die Entwickler nicht aus der Denke rauskommen, man müsse etwas skriptartiges haben um ein Setup zu bauen. Wenn man das dann krampfhaft auf MSIs überträgt kommt meistens Mist raus (und es gibt auch viele MSIs die "badly authored" sind).

Prinzipiell stimme ich sogar mit Stimmen wie diesen hier überein:

Zitat:

Zitat von sh17 (Beitrag 1086941)

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.

Es kommt in der Tat auf den Kontext des Einsatzes an und auch die traditionellen .exe-basierten Setupsysteme haben sich im Hinblick auf Rollouts im großen Stil bewegt. Aber genau wie ich bspw. .deb irgendwelchen skriptbasierten Setups als überlegen ansehe, ist's auf Windows .msi gegenüber .exe-basierten.

Wenn es denn eine bewußte Entscheidung auf Basis von Fakten ist, geht keinem etwas verloren. Wenn die Entscheidung aber auf Vorurteilen basiert, dann ist's Mist. Ich meide ja auch nicht generell Delphi-Programme, weil irgendwelche Spezis Malware mit Delphi erzeugen, oder?