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.
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.
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.
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.
Assarbad steht du neuerdings auf meiner Gehaltsliste?
Muß ich mal auf dem Konto und im Briefkasten nachgucken.
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:
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?