Installer: MSI oder nicht

[Lemmy]

Guten morgen,

Zitat von Assarbad:

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 von Lemmy:

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 von Lemmy:

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 von Lemmy:

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

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 von generic:

Assarbad steht du neuerdings auf meiner Gehaltsliste?

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

Zitat von generic:

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 von sh17:

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?