TCM 7.50a als MSI Installations-Programm

[algol]

ich bin da wirklich leidenschaftslos.

Das nehme ich in gleichem Masse auch für mich in Anspruch, obwohl ich einräume, dass unser beider Statements in den Augen Unbeteiligter womöglich auch anders interpretiert werden könnten.

dann will ich gerne einfach nur noch mal ein paar eher technische Aspekte klarstellen...

Wie gesagt: MSI ist eine Installationstechnologie, kein Inhalt.

Inzwischen fühle ich mich über die angeblichen Vorzüge der MSI-Installationstechnologie (auch das haben längst alle "geschnallt") eigentlich ausreichend informiert.

Es gibt noch einen ganz wesentlichen Unterschied zwischen der .EXE Installation-Technologie und der MSI Technologie:==> Transparenz!

Es gibt genug Werkzeuge um diese .MSI Dateien zu öffnen und um nachsehen zu können, was da passiert.

Fast hätte ich gesagt: "Da lachen ja selbst die Hühner!" Denn ohne die angedeuteten "Werkzeuge", die das OS ja nicht mitliefert, gibt es genau "0"-Transparenz. Und zweitens sehe ich überhaupt nicht ein, warum es eine "Holschuld" meinerseits für etwas geben sollte, das mir - wie so oft vielleicht nicht in seiner prinzipiellen Konzeption, wohl aber in seinen realen Ausformungen - hauptsächlich gravierende Nachteile einbringt.

Um die Analogie zu bemühen: Eine MSI Verpackung ist so etwas wie eine Klarsichthülle. Im Gegensatz dazu ist eine EXE Verpackung ein nicht zu öffnender Tresor.

Eine .EXE Installation ist eine komplette Black-Box,

Das genaue Gegenteil kann wahr sein, und gerade TC beweist es. Eine hervorragend konzipierte, selbstentpackende exe-Installation wie bei TC kann direkt eingesehen werden, alle darin enthaltenen Dateien lassen sich mit Bordmitteln auch einzeln entpacken und inspizieren.
Auch ein "unattended rollout" auf grosse Firmennetzwerke ist mit der TC-Routine transparent und ohne den MSI-typischen overhead zu realisieren. Habe ein solches rollout auch schon selbst konzipiert und danach wurde es von Mitarbeitern problemlos umgesetzt.

Die MSI-Installations-Technologie in die Nähe von Male-Ware zu rücken scheint mir absurd. MSI ist nicht der Inhalt sondern die Verpackung!

Was ich auch - und zwar insbesondere aus technischer Sicht - nicht nachvollziehen kann ist diese Sache mit der "ungebetenen und unautorisierte "Dreinpfuschen".

Dennoch erlaube ich mir, aus sachlichen Gründen vollinhaltlich zu meiner bisherigen Aussage zu stehen und diese zu begründen:

Wir wollen dazu vorerst ausschliessen, dass das zu installierende Programmpaket (der Inhalt) seinerseits irgendwelche Schadfunktionen (Viren, spyware etc.) mit einschliesst. Es sei gründlich viren-gecheckt. Nebenbei, die TC-Installationsdateien kann ich vorher auspacken und mit dem Virenchecker meines Vertrauens einzeln überprüfen. Das geht, zugegeben, nicht mit allen exe-Installroutinen, mit "den guten" aber schon, bei MSI bestenfalls mit Hilfsmitteln.

Eine saubere exe-Installation zeichnet sich nun dadurch aus, dass sie weitgehend konfigurierbar ist, keinesfalls zwangsläufig irgendwelche Pfade vorgibt, die registry nicht "zumüllt" und keinesfalls Einträge unter nicht dem Programm zuordenbaren reg.-keys hinterlässt - sowie nach dem erfolgreichen Ablauf der Routine endgültig abgeschlossen ist. Äusserstenfalls - und sehr ungern - darf nun ein einziger Neustart des Systems erforderlich sein, in dessen Verlauf noch weitere registry-Einträge erfolgen.
Unbestritten ist nun, dass eine MSI-Installation weitgehend ebenso ablaufen könnte, vom registry-overhead abgesehen, dies aber aus meiner praktischen Beobachtung kaum jemals tut.

Es wurde hier u.a. festgestellt, dass nach MSI-Deinstallation (angebliches rollback) der ursprüngliche Zustand wiederhergestellt würde. Wer dies allen Ernstes behauptet, hat nun entweder selbst keine Ahnung und plappert einfach MS-Propaganda der übleren Art einfach nach - oder aber (weil wir solches Verhalten hier niemandem unterstellen wollen), er verfügt nur über einen lausigen registry-editor, etwa nur das eingebaute regedit, der es nicht gestattet, einen exakten vorher-/nachher- Vergleich der registry 1. im ursprünglichen Zustand / 2. nach dem sogenannten rollback durchzuführen.

Nun lassen auch schlechte exe-Installationen nach "uninstall" oftmals Müll in der registry zurück, aber nach MSI-"rollback" ist die Verunstaltung der registry meist extrem, dies auch unter reg.-keys, die der Anwendung logisch gar nicht zuordenbar und - ohne direkten Vergleich - im Nachhinein daher kaum auffindbar sind.

Ein solches Verhalten ist für Malware übrigens geradezu typisch. Ebenso malwaretypisch, und damit wären wir beim Kern der Sache, ist es nun, bei laufendem Betrieb irgendwelche "-bots" ablaufen zu lassen, die unautorisierte Veränderungen am System, verborgen im Hintergrund, vornehmen. Das verstehe ich unter "Dreinpfuschen".

Und siehe da - MSI-Installationen tun das oftmals auch!! Nicht während der Installation, nein, später, bei laufendem Betrieb, werden verborgene "Helferlein" aktiv und stellen dreist einen vermeintlichen "Sollzustand" wieder her, ohne dass dies vom rechtmässigen Benutzer oder Administrator autorisiert worden wäre.

Wie sagt ein Sprichwort: Wer solche "Helferlein"=Freunde hat, braucht eigentlich keine Feinde=Viren, Malware mehr!

mfg
algol

[Lefteous]

Mir scheint ein aus meiner Sicht wichtiger Aspekt etwas zu kurz gekommen zu sein: Die Performance. MSI ist eine ziemlich merkwürdige Mischung aus Packformat und relationaler Datenbank. Wird nun ein komplexes Setup mit vielen Dateien von CD gestartet kann die MSI-Technologie für erhebliche, nicht mehr erträgliche Wartezeiten sorgen.
Selbst im Falle des TCs wird beim Starten von CD schon ein Unterschied deutlich und das Programm wird bekanntermaßen so ausgeliefert.

[Peter]

...zunächst einmal dem Programmautor das MSI Installationspaket mit dem Hinweis auf automatische Softwareverteilung in Firmennetzen schmackhaft zu machen...

Das hat er jetzt ja vor.

...bevor du dich damit unter die Wölfe der autarken Heimadministratoren begibst.

Aber er schlägt sich wacker

Peter

[ghisler(Author)]

Ich habe nichts gegen die Verbreitung des Installers als MSI. Bisher habe ich aber keine gute Lösung gefunden, wie der key mit installiert werden kann, deshalb muss man bei grossen Firmen sowieso ein eigenes MSI-Paket erzeugen. Dazu gibt es eine Anleitung:
windowsnetworking.com

Kurze Beschreibung des obigen Links:
1. WinInstall LE 2003 installieren (Link auf obiger Seite)
2. Mit WinInstall LE 2003 einen Schnappschuss auf dem Testsystem machen
3. Total Commander mit allen gewünschten Optionen installieren. Ich empfehle als Ort für die ini-Dateien die Option "Anwendungsdaten" zu waehlen.
4. Mit WinInstall LE 2003 erneut einen Schnappschuss erzeugen, um die MSI-Datei zu erzeugen
5. Die MSI-Datei über die Group Policy automatisch installieren lassen

[habi]

@ Peter
LOL

Wie gesagt, ich will weiß Gott keinen bekehren was das Thema MSI anbelangt, aber falsche Statements möchte ich eigentlich nicht stehen lassen. Ich entwickle MSI Pakete seit ca. 7 Jahren, und mit dem Thema SW Verteilung beschäftige ich mich seit nun mehr 15 Jahren. Ich weiß wahrlich auch nicht alles über MSI, aber so ganz "von gestern" bin ich diesbezüglich auch nicht - hoffe ich ... dachte ich wenigstens .



@algol
Aus meiner Erfahrung kann ich dir versichern, dass das setup von H. Ghisler eine eher seltene und rühmliche Ausnahme ist, was Transparenz anbelangt. Das ist vielleicht kein Einzelfall, aber selten - ich glaube da sind wir uns bestimmt einig.

Ich dachte wir diskutieren eher über die grundsätzlichen Vor- und Nachteile der einen- oder anderen Technologie - das TCM Setup als positives Beispiel für ein gutes EXE Setup ins Feld zu bringen ist ein cleverer Schachzug, aber schon fast unsportlich ... kleiner Scherz .

Aber zurück zum Thema.
Hast Du schon mal folgende Kommando-Zeile bei einem MSI ausprobiert?
"msiexec.exe /a anwendung.msi"

Das nennt man "Administratives Setup" (wobei es verschiedene Begriffe dafür gibt).

Damit extrahierst Du sämtliche Dateien des Setups (sofern diese über die entsprechenden MSI Tabellen definiert wurden) in ein Verzeichnis, das Du angeben kannst.

Unter "0" Transparenz verstehe ich etwas anderes

UND (korrigiere mich, wenn ich mir irre):
Du kannst zwar die Dateien aus dem .EXE Setup des TCM heraus holen, aber die wirkliche Installations-Logik kannst Du NICHT sehen. Warum z.B. möglicherweise die eine Version einer Datei installiert wird und nicht die andere (z.B. eine Variante für 32bit System und eine andere für 64bit Systeme) weiß nur der Setup Entwickler, soweit kannst Du in ein .EXE nicht hineinsehen. Bei MSI geht das schon, wenn man das wissen möchte (z.B. für Trouble Shooting).


Das mit der Holschuld habe ich nicht verstanden.
Es geht ja nicht um das holen müssen von Informationen, sondern um das können (!).

Bei MSI kann man, bei EXE (von rühmlichen Ausnahmen abgesehen) in aller Regel nicht (und schon gar nicht im Detail bzgl. Installationslogik).

95% aller Hersteller Setups werden mit InstallShield erstellt. Bei denen kann man noch nicht einmal die .CAB Dateien öffnen (zumindest nicht dass ich wüsste einfach mal so).

Und abgesehen von dem kostenlosen MS Tool "Orca" (dem man natürlich mistrauen kann, weil MS), liefert Google jede Menge Treffer, wenn man nach "msi editor freeware" sucht.
Und dann gibt es ja auch noch die professionellen Tools wie z.B. von Wise/Symantec, die man als Eval Version herunter laden kann.

Also wer will hat wirklich viele Möglichkeiten ein MSI zu analysieren.




Thema Viren:
Wie gesagt, mit /a kann man i.d.R. alle MSI Pakete "öffnen", also zumindest die sich darin befindlichen Dateien extrahieren und damit auch auf Viren checken.

Und wenn ein Hersteller "custom actions" zum Installieren von Dateien anstelle von MSI Tabellen verwendet (und damit wieder eine black-box verwendet, weil man über /a NICHT einsehen kann, was da passiert), dann sollte er wenigstens einen sehr guten Grund dafür haben.

BTW … es gibt übrigens sogar ein PlugIn für den TCM, mit dessen Hilfe man MSI Dateien wie eine ZIP Datei öffnen kann:
http://www.ghisler.com/plugins.htm
=> MSI 1.2

"Touchée" würde ich sagen .

Unbestritten ist nun, dass eine MSI-Installation weitgehend ebenso ablaufen könnte, vom registry-overhead abgesehen, dies aber aus meiner praktischen Beobachtung kaum jemals tut.

Tja, da kann ich Dir durchaus zustimmen, aber das kann man nicht der Technologie anlasten, sondern das liegt am Entwickler des Setups. So wie es gute und schlechte EXE Setups gibt, so gibt es auch gute und schlechte MSI Setups.

Es wurde hier u.a. festgestellt, dass nach MSI-Deinstallation (angebliches rollback) der ursprüngliche Zustand wiederhergestellt würde. Wer dies allen Ernstes behauptet, hat nun entweder selbst keine Ahnung und plappert einfach MS-Propaganda der übleren Art einfach nach - oder aber (weil wir solches Verhalten hier niemandem unterstellen wollen), er verfügt nur über einen lausigen registry-editor, etwa nur das eingebaute regedit, der es nicht gestattet, einen exakten vorher-/nachher- Vergleich der registry 1. im ursprünglichen Zustand / 2. nach dem sogenannten rollback durchzuführen.

Ollala ... starker Tobak . Muß ich mich da angesprochen fühlen? Erstens plappere ich nichts nach, zweitens arbeite ich nicht mit lausigen Tools (bei allem Respekt: Wer Wise Package Studio ernsthaft als lausiges Tool bezeichnet hat nun wirklich selber keine Ahnung) und drittens bilde ich mir zumindest ein, ein bisschen mehr als Bücherwissen in Bezug auf die MSI Technologie zu haben.

Fazit: Ich fühle mich nicht angesprochen

Kann es sein, dass Du Roll-Back und Uninstall verwechselst, bzw. in einem Topf wirfst?

Wenn eine MSI Installation anfängt Dateien zu installieren, und dabei ggf. vorhandene Dateien überschreibt, so werden die überschriebenen Dateien zunächst einmal temporär (so lange die Installation läuft und noch nicht erfolgreich abgeschlossen wurde) in C:\config.msi zwischen gespeichert.
War die Installation aus Sicht von MSI erfolgreich wird dieser Ordner gelöscht (manchmal bleibt tatsächlich auch ein leerer Ordner zurück - ja ... das ist dann Müll ).
War die Installation NICHT erfolgreich, so werden die temporär zwischen-gespeicherten originalen Dateien zurück kopiert, so dass (zumindest mehr oder weniger im Rahmen des sinnvollen und möglichen) der ursprüngliche System Zustand wieder hergestellt wird.

Das ist die Default Einstellung und eine im MSI System grundsätzlich integrierte Basis-Funktionalität!

Mag sein, dass das je nach Komplexität eines Setups und nicht zuletzt bedingt durch die spezifische Systemumgebung nicht immer 100% perfekt funktioniert, aber das jeweils betroffene System bleibt mit extrem hoher Wahrscheinlichkeit zumindest in einem so guten Zustand, dass man damit weiter arbeiten kann, und auch die anderen Anwendungen korrekt funktionieren! Gäbe es diesen Rollback nicht würde so mancher Rechner nach einer abgebrochenen Installation den nächsten Reboot nicht mehr überleben.

Und jetzt zeig mir mal eine ähnliche Technologie aus der .EXE Welt, die auch wirklich jemand in sein .EXE Setup implementiert hat! Nicht dass das nicht auch mit .EXE möglich wäre, aber aus meiner Erfahrung weiß ich: Das macht niemand!

Das mit dem Roll-Back kannst Du ja mal selber mit einem MSI Setup Deiner Wahl ausprobieren. Voraussetzung ist natürlich, dass es auch etwas zum Zwischenspeichern gibt. Dann mal C:\config.msi beobachten.




OK ... ich arbeite halt viel in großen Umgebungen, und da sind mir (und wohl den meisten Systemadministratoren) pragmatische Lösungen die funktionieren einfach wichtig. Prio eins bei einem RollOut auf 5000 Rechner ist eine hohe Erfolgsquote und dass die Rechner nach einer Installation wenigstens wieder booten. Ob da mal der eine oder andere Key, oder die eine oder andere Datei nach einer Deinstallation zurückbleiben (vielleicht ist das ja sogar ganz sinnvoll - siehe wincmd.ini) ist da eher ein akademisches Thema.

Nicht während der Installation, nein, später, bei laufendem Betrieb, werden verborgene "Helferlein" aktiv und stellen dreist einen vermeintlichen "Sollzustand" wieder her, ohne dass dies vom rechtmässigen Benutzer oder Administrator autorisiert worden wäre.

In großen Umgebungen sind das keine "vermeintlichen" Sollzustände, diese vordefinierten Installationszustände sind eine für einen effizienten Betrieb von PC Systemen unumgängliche Notwendigkeit, mit Dreistigkeit hat das nichts zu tun.
Diese Helferlein sind auch keine unbekannten, gar unberechenbare oder gar böswilligen Kobolde sondern sind durchaus gute Bekannte (wenn man sich überwindet sie näher kennen lernen zu wollen ).
Das Helferlein hört übrigens auf den Namen "Self-Repair" und ich würde es eher als gutartiges Heinzelmännchen bezeichnen . Jedenfalls habe ich persönlich noch nie gehört, dass nach einem MSI-Repair eine Anwendung nicht mehr funktioniert hätte, die hat i.d.R. davor nicht mehr funktioniert, bzw. wahrscheinlich hat man (Benutzer) noch nicht einmal gemerkt, dass die Anwendung nicht mehr funktioniert hat, weil ja der Self-Repair bereits beim Programm-Start alles wieder in Ordnung gebracht hat. Übrigens werden bei einem Self-Repair keine Programm-Konfigurationen geändert, zumindest nicht wenn man das richtig macht (das MSI).


@lefteous
Guter Punkt, in der Tat.

Es gibt diesbezüglich tatsächlich ein paar Dinge, die man (der Entwickler) beachten muß/kann.

Wenn man z.B. beim Kompilieren eines MSIs festlegt, dass nur EIN einziges MSI erzeugt wird (also kein .msi Datei + externe .cab Datei), dann wird bei der Installation eines MSI Setups die IN dem MSI befindliche .CAB Datei temporär erst einmal extrahiert.

Das kostet Zeit.

Kann man aber auch anders machen indem man z.B. ein .MSI PLUS eine externe .CAB Datei erzeugt.
Letzteres ist aber eher die Ausnahme, eine Distribution ist mit einem MSI ohne zusätzliche .CAB Datei(en) "sicherer" - User/Administrator könnte die .CAB Datei "vergessen" - Installation läuft nicht => Prio 1: Vermeidung von potentiellen Fehlermöglichkeiten!

Aber auch das Zwischenspeichern der "Roll-Back" Dateien kostet natürlich Performance, hier wird Sicherheit durch mehr Zeit erkauft.

Insofern stimmt das schon, eine MSI Installation ist wohl eher langsamer als eine .EXE Installation.

Aber wenn wir mal ehrlich sind: Selbst bei einer manuellen Installation kommt es nicht wirklich auf Performance an, wir sind ja nicht auf der Flucht.
Und in einer großen Umgebung ist Performance an dieser Stelle nun wirklich das letzte, worüber man sich "einen Kopf macht".

@ karlchen
Gut gebrüllt Löwe . Ungeschick lässt grüßen. Gut gemeint, aber ungeschickt ausgeführt, so sieht es wohl aus.
Und wie ich oben schon geschrieben habe: Es gibt sogar ein PlugIn für den TCM um Dateien aus einem MSI zu extrahieren.



@ C. Ghisler
Freut mich zu hören, dass das mit dem MSI OK ist. Wir hatten ja schon vor einiger Zeit mal darüber gesprochen, bzw. uns per Mail ausgetauscht. Ich hatte das Thema nur aus zeitlichen Gründen wieder etwas vertagen müssen.

Mein Anliegen ist ja nun wirklich nur der TCM Fan-Gemeinde etwas aus meiner Sicht positives beizusteuern.
Ich habe auch in den Foren gesehen, dass MSI und Rollout immer wieder mal ein Thema war. Und aus vielen Paketierungs-Projekten weiß ich, "wo der Schuh drückt" wenn es um das Automatisieren und Konfigurieren von Anwendungen geht.

Ein MSI Setup ist keine Notwendigkeit, bei einer manuellen Einzelplatz Installation schon gar nicht, das hatte ich ja bereits geschrieben. Aber alle (oder zumindest die meisten) Systemadministratoren die Software verteilen müssen bevorzugen i.d.R. ein MSI Setup. Da weiß man was drin steckt und wie das Setup tickt. Man sieht welche Properties verwendet werden und man versteht i.d.R. schnell, wie man diese für seine (Kunden) Bedürfnisse einsetzen, sprich konfigurieren kann (selbst wenn es keine Doku gibt).
Und für kleinere Änderungen genügt durchaus das kostenlose Tool "Orca" von MS. Damit erstellt man ein Transform ohne das Hersteller-Setup verändern zu müssen.

wie der key mit installiert werden kann, deshalb muss man bei grossen Firmen sowieso ein eigenes MSI-Paket erzeugen.

Wie ist das mit dem Key gemeint? Es gibt doch die wincmd.key Datei, die zur Lizensierung benötigt wird?!?

Hat man ein MSI Setup (ohne Lizenz-Key), so muß der Paketierer lediglich ein MSI TRANSFORM erstellen, das die entsprechende Lizenz-Datei quasi zur Laufzeit der Installation mitgibt. Dabei macht es vom Aufwand keinen wesentlichen Unterschied, ob eine Lizensierung per Datei (wie beim TCM) oder z.B. per Reg-Key umgesetzt wird.
Den Aufwand für die Erstellung des TRANSFORMS würde ich auf ca. 5 Minuten schätzen (egal ob Datei oder Registry Lizensierung).

Denkbar wäre auch eine Custom Action zu implementieren, die während einer Installation im Verzeichnis, in dem auch das MSI Setup liegt, nachsieht, ob es dort eine wincmd.key Datei gibt und wenn ja, diese Datei in das Installationsverzeichnis des TCM kopiert.

Also ... da kann man sich bestimmt mehrere Lösungen ausdenken.

Ein grundsätzliches Thema ist auch, ob es vom Hersteller erlaubt (toleriert wird), dass bei einem Massenrollout immer die selbe (!) wincmd.key Datei verteilt wird, etwas anders ist nämlich nicht ohne größeren Aufwand realisierbar.
Entscheident sollte letztendlich sein, dass der Kunde ausreichend Lizenzen gekauft hat. Aber das ist meine persönliche Meinung.





vg,
Hans

[Peter]

....Das Paket kann hier herunter geladen werden:
>> svsdownloads . de << im Download-Bereich => Tools & Utilities....

Da habe ich jetzt mal kurz vorbei geschaut und gebe zu bedenken:

- Die Seite ist deutschsprachig - damit gibt es für viele TC-Anwender die erste Hürde.

- Man muß sich registrieren - das ist auch nicht das, was motiviert.

Hast du schon angedacht, dass Paket auf totalcmd.net bereitzustellen? Englisch, sehr frequentiert, ohne Registration ....

Peter

[algol]

Hast Du schon mal folgende Kommando-Zeile bei einem MSI ausprobiert?
"msiexec.exe /a anwendung.msi"

Wenn Dir 100+ Male reichen? Mancher mag vielleicht glauben, dass ich auf dem Mond lebe. Soll er doch! Aber, wie ich zu sagen pflege, derjenige möge dann getrost davon ausgehen, ich lebe garantiert nicht dahinter!

Und so kommt es, dass ich auch aus Deinem letzten post trotz all seiner Ausführlichkeit keinerlei für mich neue Informationen zum Thema gewinnen konnte, ich fühle mich - wie bereits erwähnt - ausreichend dazu informiert.

Gerade deshalb kann ich auch mitteilen, dass ich schon Fälle beobachtet habe, wo sich nach MSI-Installation ein paar Dateien mehr im System tummelten, als beim Entpacken mit "msiexec.exe /a ..." zu sehen waren, und ich spreche hier nicht von .ini oder Konfigurationsdateien, die während der Installation frisch erzeugt wurden.

Ollala ... starker Tobak . Muß ich mich da angesprochen fühlen? Erstens plappere ich nichts nach, zweitens arbeite ich nicht mit lausigen Tools (bei allem Respekt: Wer Wise Package Studio...

Nicht unbedingt. Tust Du ja auch nicht. Und offenbar zurecht. Denn bei Verwendung von "Wise Package Studio" und hoffentlich auch eines ähnlich mächtigen registry-editors/snapshot-tools ist es Dir ja ein Leichtes, Dich davon zu überzeugen, dass nach einem simulierten rollback so mancher MSI-Installation es in Teilen der registry eher aussieht wie in einem Schweinestall (symbolisch gesehen), verglichen mit dem _tatsächlichen_ Zustand vor der Installation, der ja _angeblich_ wieder hergestellt wird.
Dass sich die registry danach nicht mehr defragmentieren liess und irreversibel korrupt war, ist auch schon beobachtet worden.

War die Installation NICHT erfolgreich, so werden die temporär zwischen-gespeicherten originalen Dateien zurück kopiert, so dass (zumindest mehr oder weniger im Rahmen des sinnvollen und möglichen) der ursprüngliche System Zustand wieder hergestellt wird.

Derartig leichtfertige Standards von "mehr oder weniger" ursprünglichen Zuständen kann und will ich mir in meinem Verantwortungsbereich einfach nicht leisten. Soll ein neues Programmpaket auf systemkritischen Rechnern installiert werden, das nur als MSI package vorliegt, so darf dieses - nicht zuletzt nach obigen Erfahrungen - zunächst nur auf einer "virtual machine" mit simulierter Netzanbindung ausgetestet werden, dafür habe ich gesorgt.

Das mit dem Roll-Back kannst Du ja mal selber mit einem MSI Setup Deiner Wahl ausprobieren. Voraussetzung ist natürlich, dass es auch etwas zum Zwischenspeichern gibt. Dann mal C:\config.msi beobachten.

Wird routinemässig gemacht und führt laufend zu Ärger.

Ob da mal der eine oder andere Key, oder die eine oder andere Datei nach einer Deinstallation zurückbleiben (vielleicht ist das ja sogar ganz sinnvoll - siehe wincmd.ini) ist da eher ein akademisches Thema.

Supporter, die so denken, sind ein Gottesgeschenk - an den Mitbewerb!

In großen Umgebungen sind das keine "vermeintlichen" Sollzustände, diese vordefinierten Installationszustände sind eine für einen effizienten Betrieb von PC Systemen unumgängliche Notwendigkeit, mit Dreistigkeit hat das nichts zu tun.

Das hat nicht "nichts" mit Dreistigkeit zu tun - sondern "alles" und ausschliesslich! Denn in grossen Umgebungen gibt es so viele individuelle und von aussen unvorhersehbare Nebenbedingungen, dass fast immer sehr spezifische, _tatsächliche_ Installations-Sollzustände vorliegen.

Nur, die haben ausschliesslich die verantwortlichen Spezialisten des Unternehmens/der Institution festzulegen und die Administratoren haben diese dann umzusetzen bzw. auszuführen.

Da schlägt's doch wirklich "13", wenn irgendeine dahergelaufene, für den Massenmarkt konfektionierte 08/15-Installationsroutine "glaubt"= von ihren Machern dazu gebaut wird, aus ihrer lächerlichen Froschperspektive unsere spezifischen Installationszustände und -notwendigkeiten erkennen zu können und dann womöglich noch unaufgefordert diese vermeintlichen - weil falsch erkannten - Pseudo-Sollzustände wiederherstellen zu müssen.

mfg
algol

[habi]

@algol
Nichts für ungut und bei allem Respekt: Tatsächlich finde ich in Deinem letzten Beitrag auch nur wenig sachlich erhellendes, eher ein trotziges drauf hauen wollen auf MSI um jeden Preis.

Ich halte immer noch eine Differenzierung zwischen Inhalt und Verpackung bei diesem Thema für die grundlegend Basis einer sachlichen Diskussion.
MSI ist eine Verpackungs-Technologie, die bei allen Schwächen deutliche strukturelle Vorteile gegenüber der .EXE Technologie hat (egal mit welchem Tool das .EXE entwickelt wurde und wie gut es im einzelnen auch immer gemacht sein mag).

Wenn ein Hersteller ein schlechtes .MSI gemacht hat (und da bin ich ja bei Dir: Davon gibt es leider mehr als genug), dann kann man das aber nicht pauschaliert der Technologie anlasten.

Ich kann ja auch nicht sagen Messer und Gabel wären Teufelszeug, nur weil mir mein Gegenüber bei entsprechender Ungeschicklichkeit auch ein Auge ausstechen könnte (ich esse jedenfalls nicht mit den Händen ).

Insofern denke ich sollten wir es dabei belassen, jeder kann sich nach dieser Diskussion seine eigenen Gedanken zum Thema .MSI oder .EXE machen.

Ich bin eh ein Verfechter der These, es gibt kein RICHTIG oder FALSCH (zumindest im technischen Bereich), sondern ein PASST, PASST-NICHT, PASST-BESSER oder SCHLECHTER, usw..

Es kommt immer auf viele Randbedingungen an:
* Budget
* Sicherheit
* Stabilität
* Spezifisches System-Umfeld
* Konzern-Strategie
* Persönliche Vorlieben
Und vieles mehr!

Und nicht zuletzt gibt es in den meisten Unternehmen auch noch höher bezahlte Meinungen, die sich rational nicht immer erschließen lassen .


Ich kenne Unternehmen und große System-Umgebungen, die genau das machen wie Du das siehst: Wenn es vom Hersteller ein .EXE Setup gibt, dann wird dieses genommen, silent-gemacht (sofern möglich), dann ein bisschen Script drum rum gebastelt für die Konfiguration der Anwendung, und ab geht die Post.

Keine Frage: Kann man machen. Funktioniert auch auf den ersten Blick gar nicht schlecht.
Ich kenne genug Beispiele dafür.

Aber aus tiefster Überzeugung glaube ich, dass hier die Rechnung ohne den Wirt gemacht wird.

Oder anders gesagt: Es wird zu kurz gedacht.

Meine Überzeugung ist: Selbst wenn ich den Aufwand betreibe aus einem Hersteller Setup .EXE ein MSI Setup durch Repaketierung zu machen um es in großen System-Umgebungen hunderte oder tausende Male zu installieren, es zahlt sich aus (und selbst wenn ich nur auf 50 Rechner verteile)! Der höhere initiale Aufwand wird durch eine höhere Erfolgsquote in Bezug auf Installation, Konfiguration und letztendlich ein stabileres Betriebsverhalten der Anwendung belohnt.
Und das bedeutet: Weniger Supportkosten=Betriebskosten!

Wenn ich also eine kostenmäßige Gesamtbetrachtung über den Lebenszyklus einer Anwendung mache, dann sieht die Bilanz für MSI nicht schlecht aus.

Das ist bei der Software nicht anders wie bei Hardware. Die Betriebskosten eines Rechners übersteigen die Anschaffungskosten im Laufe eines Rechner-Lebens von vielleicht 2-4 Jahren um ein Vielfaches.


Aber bei wenigen Einzelplatzinstallationen kann man darüber natürlich diskutieren, das hatte ich glaube ich schon gesagt.
Es kommt halt immer auf die konkrete Situation an, was Sinn macht oder nicht.



Aus meiner Erfahrung kann ich auch sagen: Die Tendenz geht eindeutig dahin, dass es immer mehr .MSI Setups gibt, und immer weniger .EXE Setups.

Wobei ich denke, dass das in den nächsten Jahren eh in eine ganz andere Richtung gehen wird, nämlich Anwendungs-Virtualisierung. Ob das nun Microsoft, VMWare, Symantec, Citrix, oder eine der vielen anderen Anbieter mit ihren jeweiligen Technologien sein wird, die Anwendungs-Virtualisierung wird die klassische Installation ablösen, ob nun .EXE oder .MSI.


In diesem Sinne algol - lass uns die Hände schütteln





Wer das von mir erstellte MSI nutzen möchte darf, wer nicht will muß auch nicht.

Über sachliche/fachliche Kritik freue ich mich jederzeit!
Wenn es etwas zu verbessern gibt (und das gibt es immer), dann einfach melden.


@Peter

- Die Seite ist deutschsprachig - damit gibt es für viele TC-Anwender die erste Hürde.

Da svsdownloads.de eigentlich das Thema Virtualisierung zum Schwerpunkt hat, und es bereits eine hervorragende englischsprachige Seite dazu gibt (www.sysmantec.com/connect) wollte ich die Seite bewusst sehr deutschsprachig halten, aber so ganz lässt sich das wohl nicht durchhalten. D.h. ich werde das mit einem englischen Teil ergänzen.

Man muss sich registrieren - das ist auch nicht das, was motiviert.

Fair point .
Ich habe das jetzt mal so gemacht: Wer nur das MSI Setup herunter laden möchte kann das direkt ohne Anmeldung tun, es gibt einen entsprechenden Download-Link.
Wer auch die Entwicklungs-Sourcen haben möchte (Wise .WSI und .WSE Dateien) muss sich anmelden. Es steckt schon einiges an Entwicklungsaufwand in dem MSI Setup drin, da würde ich doch zumindest gerne wissen, wer und wie oft sich jemand dafür interessiert, wobei mir natürlich auch klar ist, dass es genug anonyme Mail-Accounts gibt.

Hast du schon angedacht, dass Paket auf totalcmd.net bereitzustellen? Englisch, sehr frequentiert, ohne Registration ....

Guter Hinweis, danke!
Mal abgesehen davon, dass die Seite vor ein paar Tagen down war, und mal abgesehen davon, dass ich ziemlich wenig über den Betreiber der Seite finde, ist das vielleicht keine schlechte Option.
Hast Du da Kontaktdaten? Oder einfach mal an info@totalcmd.net mailen?



vg,
Hans

[tumasch]

Ich will euch 2 nicht unterbrechen, aber meiner Meinung nach ist MSI mit etwas vom schlechtesten, was MS jemals zustande bekommen hat - so neben Windows 2.03 und Paint.

Zu einen brauchen MSI abartig viel Platz. Schon mal eine normale MSI mit weniger als 20MB gesehen? Selten. Dazu kommt noch windows\installer\. Muss der Quatsch wirklich sein, dass 20% des Plattenplatzes für irgendwelche Backups benötigt werden?

BTW: Office 2K3 ist so ein sinnvolles Beispiel: Installiert man es defaultmässig, so werden nicht alle Optionen installiert, sondern die Hälfte landet in einem Verzeichnis MSOCache. Wozu das ganze? So spart man Plattenplatz sagt MS. Aha. Selten so was von dämlich gesehen. Dann kann man es ja auch komplett installieren, wenns ja sowieso auf der Platte landet. Bravo.

Die Autoreparatur funktioniert in den allermeisten Fällen sowieso nicht. Dann fragt er nach irgendwelchen MSI-Paketen, und gibt man ihm diese, funktioniert es trotzdem nicht. Bricht man den sch**** dann genervt ab, funktioniert die Applikation aber problemlos - häh?

Eine Reparaturinstallation funktioniert meist auch nicht, da der Installer veränderte Dateien ja nicht überschreibt - es könnte ja was wichtiges sein!. So ein Käse. Ein dedizierter Installer weiss welche Dateien er ersetzen muss und kann und welche nicht.

Ein gutes Programm braucht normalerweise genau 3 Dinge: Eine EXE und die DLLs und Datendateien in einem bestimmten Programmverzeichnis, eine INI resp. ein REG-Eintrag in HKCU\SOFTWARE und ein Eintrag ins Startmenü. Und dass kann ein jeder EXE-Installer auch ohne MSI. Und die Reparatur ersetzt diese Dateien und alles geht wieder. Aber wieso einfach, wenns auch kompliziert geht?

Zudem lassen sich praktisch alle EXE-installer als silent-installation starten (/S in 99% der fälle). MSI muss man meiste zuerst irgendwas basteln, bevor es geht.

Ich habe das Gefühl, dass MSI vorwiegend erfunden wurde, damit unfähige Programmierer ihre Applikationen auch pseudoprofessionell vertreiben können. Zeig mir mal ein MSI, das einfach das tut, was es soll: Ein Programm installieren und später wieder das Programm rückstandsfrei entfernen. Das muss zuerst noch erfunden werden.

Oder versuch mal, die MSI für das .NET Framework zu installieren, wenn mal was nicht richtig läuft. Ist nahezu unmöglich. Um die Software zu deinstallieren wollte er sie erst installieren, was aber nicht ging, weil sie nicht richtig installiert war ... AGRH! Nach stundenlangem suchen und löschen von gefühlt einer Millionen Keys in der Registry und von Dateien im Dateisystem konnte ich es dann wieder neu installieren. Toll. Mit einem EXE-Installer hätte das keine 10 Sekunden gebraucht.

Zusammenfassend sage ich (meine Meinung !!!) dass MSI Dreck ist und Softwareverteilung auch ohne MSI wirklich toll funktionieren kann.

Natürlich spielt immer eine Rolle, wer jetzt genau die MSI gemacht hat, aber da gibt es wahrscheinlich einfach nicht genügend qualifizierte Leute.

Soweit meine Erfahrungen in den letzten paar Jahren betreffend MSI...

[tumasch]

Ach ja: Dein Argument "Ein Abbruch der Installation ist ohne MSI ein Glücksspiel" kann man nicht gelten lassen: Eine Software, die das System derart verbiegt, dass Systemdateien ersetzt werden müssen und die Gefahr eines Systemdefektes besteht, ist meiner Meinung nach broken by design und ein Fall für die Tonne. Es geht auch ohne.

[klsgfx]

So als kurzer Einwurf:

Mein größtes Problem mit diesem MSI: Woher weiß ich, dass der enthaltene TC auch das (nicht modifizierte) Original von CG ist?
Nicht daß ich Hans mißtrauen würde, aber kann ich ihm trauen?
(No offence meant!)

Oder habe ich etwas übersehen?

Gruß,
Klaus

[habi]

hmmpf ... ich dachte ich hätt's hinter mir

Wie immer liegt die Wahrheit irgendwo in der Mitte.

Ich will euch 2 nicht unterbrechen, aber meiner Meinung nach ist MSI mit etwas vom schlechtesten, was MS jemals zustande bekommen hat

Wenn mich nicht alles täuscht wurde die Windows Installer Technologie gar nicht von MS erfunden sonder zugekauft (von Wise?). Ist aber auch grundsätzlich egal denke ich, es wurde vom "Feindbild" "assimiliert".

Schon mal eine normale MSI mit weniger als 20MB gesehen?

Ja. Das MSI Setup das ich für den TCM 7.50a gemacht habe hat ein Dateigröße von ca. 4,4 MB, das originale Setup hat 3,2 MB, also in der Tat ein bisschen weniger. Tatsächlich sind das sogar rund 25% weniger, also gar nicht mal so unerheblich. Aber das relativiert sich bei größeren Anwendungen schnell. Ich mußte auch eine kleine CustomAction einbauen, um den Deinstallations-Mechanismus der originalen Deinstallation-Mechanik in Bezug auf das Entfernen der INI Dateien nachzubauen. Aber ist das wirklich wichtig, wie groß das Installations-Setup ist? Wenn ja, warum?

Dazu kommt noch windows\installer\. Muss der Quatsch wirklich sein, dass 20% des Plattenplatzes für irgendwelche Backups benötigt werden?

Wenn Du eine 100 MB (und ich meine Mega Byte) Platte hast liegst Du mit den 20% vermutlich richtig. Ich habe in meinem zugemüllten NB mit Windows 7 eine 500 GB Platte drin und mein Windows\Installer Verzeichnis ist 3,7 GB groß. Macht nach Adam Riese deutlich weniger als 1%. Wie bist Du auf die Zahl 20% gekommen?

BTW: Office 2K3 ist so ein sinnvolles Beispiel: Installiert man es defaultmässig, so werden nicht alle Optionen installiert, sondern die Hälfte landet in einem Verzeichnis MSOCache. Wozu das ganze? So spart man Plattenplatz sagt MS. Aha. Selten so was von dämlich gesehen. Dann kann man es ja auch komplett installieren, wenns ja sowieso auf der Platte landet. Bravo.

Die Argumentation von MS kenne ich nicht, aber in der Tat finde ich das auch schwachsinnig, dass nicht gleich alles installiert wird - per default. Aber: Das hat mal wieder nicht per se etwas mit der Installer-Technologie zu tun sondern mit der Art der Ausführung eines speziellen Setups.

Die Autoreparatur funktioniert in den allermeisten Fällen sowieso nicht. Dann fragt er nach irgendwelchen MSI-Paketen, und gibt man ihm diese, funktioniert es trotzdem nicht. Bricht man den sch**** dann genervt ab, funktioniert die Applikation aber problemlos - häh?

Hier muss man differenzieren in Bezug auf die Version des Installers. In früheren Versionen hat MSI selbst dann die originalen Sourcen benötigt, wenn es nur um die Reparatur von Reg-Keys ging. Blöd. Funktioniert aber zuverlässig besser mit den aktuellen Versionen (ich glaube so ab Version 3.x). Wenn es nur um die Reparatur von MSI Keys geht werden keine externen MSI Quellen benötigt (nur die im Windows\Installer gecachte Mini-MSI Datei).
Wenn die MSI Reparatur explizit nach den Quellen fragt dann muss man natürlich darauf achten, EXAKT die richtigen zu liefern. Wenn man ein deutsches Office installiert hat muss man auch die EXAKT richtige DVD einlegen (nicht etwa eine englische oder anstelle einer Standard-Version ein Prof. Version, usw.. Es geht hier um den ProductCode - der muss halt passen. Und wenn er passt, dann funktioniert das auch.

Ob die Anwendung nach einem abgebrochenen Repair funktioniert hängt letztendlich davon ab, welches konkrete Problem vorliegt. Das kann man also überhaupt nicht verallgemeinern.

Eine Reparaturinstallation funktioniert meist auch nicht, da der Installer veränderte Dateien ja nicht überschreibt - es könnte ja was wichtiges sein!. So ein Käse. Ein dedizierter Installer weiss welche Dateien er ersetzen muss und kann und welche nicht.

Auch das ist so pauschal gesagt schlicht nonsense. Um die ganzen komplexen Mechanismen hier darzustellen würde der Platz nicht reichen. Such mal im Internet nach "msi.chm" - und dann such dort mal nach "File Versioning Rules". Im Übrigen gibt es auch Commando-Zeilen Parameter für einen MSI Reparatur, mit der man auch neuere Versionen einer Datei durch ältere ersetzen kann - wenn es denn sein muss.

Wie immer: Es hängt vom Design des MSIs ab, was, wann und wie bei einem Repair passiert oder auch nicht.

Ein gutes Programm braucht normalerweise genau 3 Dinge: Eine EXE und die DLLs und Datendateien in einem bestimmten Programmverzeichnis, eine INI resp. ein REG-Eintrag in HKCU\SOFTWARE und ein Eintrag ins Startmenü. Und dass kann ein jeder EXE-Installer auch ohne MSI.

Wer hat das bestritten?

Es gibt ja bei MSI die Möglichkeit einen manuellen Repair von Anwendungen durchzuführen, aber man kann eben auch (wenn man das so WILL) einen automatischen Repair möglich machen (man KANN, MUSS aber nicht).
Woher nun sollen die Informationen kommen, WIE eine Anwendung RICHTIG installiert ist?? Offensichtlich müssen diese Informationen irgendwo auf dem lokalen System abgelegt sein (wenn ich nicht schon für die Überprüfung einen Zugriff auf die originalen Sourcen haben will, und wer würde das wollen???). Dazu gibt es einerseits die lokal gecachte Installations-MSI (windows\Installer Verzeichnis), die aber OHNE binäre Sourcen dort gecacht wird (sonst wären wir wohl bei deinen 20%). Andererseits gibt es dafür die vielen kleinen und bösen Registry-Keys in denen z.B. steht, wo welche(r) Datei/RegKey gesucht und überprüft werden soll.

Jep, so ist, wenn man die Möglichkeit (den Luxus) für einen AUTOMATISCHEN Repair haben möchte (nicht muss).

Zudem lassen sich praktisch alle EXE-installer als silent-installation starten (/S in 99% der fälle). MSI muss man meiste zuerst irgendwas basteln, bevor es geht.

Mit Verlaub: Das ist nun wirklich Unsinn. Von extrem wenigen Ausnahmen abgesehen lassen sich alle MSI mit dem Schalter /qirgendwas silent machen!

Das sagt msi.chm dazu:

Sets user interface level.
q , qn - No UI

qb - Basic UI. Use qb! to hide the Cancel button.

qr - Reduced UI with no modal dialog box displayed at the end of the installation.

qf - Full UI and any authored FatalError, UserExit, or Exit modal dialog boxes at the end.

qn+ - No UI except for a modal dialog box displayed at the end.

qb+ - Basic UI with a modal dialog box displayed at the end. The modal box is not displayed if the user cancels the installation. Use qb+! or qb!+ to hide the Cancel button.

qb- - Basic UI with no modal dialog boxes. Please note that /qb+- is not a supported UI level. Use qb-! or qb!- to hide the Cancel button.

Note that the ! option is available with Windows Installer 2.0 and works only with basic UI. It is not valid with full UI.


Zeig mir mal ein .EXE Setup, das mir diese Möglichkeiten bietet!
Und wieder gilt: Man HAT diese Möglichkeiten. Ob und welche ich nutze hängt von dem ab was ich erreichen will.

Ich habe das Gefühl, dass MSI vorwiegend erfunden wurde, damit unfähige Programmierer ihre Applikationen auch pseudoprofessionell vertreiben können.

Hmmm ... für mich ist das Polemik (und darüber hinaus eine Beleidigung für wohl jeden Programmierer, der ein MSI Setup verwendet ... und das sind verdammt viele) .
[...]Der Polemiker sucht nicht zwingend den Konsens, sondern versucht im rhetorischen Wettstreit seinen Argumenten zum Durchbruch zu verhelfen (vgl. auch Eristik)[...] => Siehe Wikipedia.
Das macht man, wenn man keine guten Argumente hat.

Zeig mir mal ein MSI, das einfach das tut, was es soll: Ein Programm installieren und später wieder das Programm rückstandsfrei entfernen. Das muss zuerst noch erfunden werden.

Das hängt von der Definition von "Rückstandfrei" ab. Man kann das natürlich zu 100% definieren, eben alles. Aber dann zeig mir mal ein .EXE Setup, dass das zu 100% macht! Selbst das originale TCM Setup ist da nicht immer mit 100% dabei. Und das ist noch eins der guten! Und dann gibt es da noch diejenigen Dateien, die übrig bleiben, weil Sie entweder neu dazugekommen sind (typisch z.B. die Index .gid Dateien aus den alten .hlp Dateien), oder die sich geändert haben.

Wie hättest Du es denn gern?
Würde ALLES gelöscht würden käme das Gemecker: Wie kann sich denn ein Programm erdreisten, geändert Dateien zu löschen!
Bleiben solche Sachen übrig (zu Recht, meiner Meinung nach), dann kommt das Geschrei, dass was übrig bleibt!

Und schon wieder ist es so, dass es vom Design des MSI abhängt, was passiert! Der Default ist wie oben beschrieben, aber nichts ist leichter, als die große Keule "ich lösch alles" einzubauen!

Oder versuch mal, die MSI für das .NET Framework zu installieren, wenn mal was nicht richtig läuft. Ist nahezu unmöglich. Um die Software zu deinstallieren wollte er sie erst installieren, was aber nicht ging, weil sie nicht richtig installiert war ... AGRH! Nach stundenlangem suchen und löschen von gefühlt einer Millionen Keys in der Registry und von Dateien im Dateisystem konnte ich es dann wieder neu installieren. Toll. Mit einem EXE-Installer hätte das keine 10 Sekunden gebraucht.

Wenn das IMMER so problematisch wäre, hätten Millionen von Usern dieses Problem. Wenn es NICHT immer so problematisch ist, dann hat wohl das spezifische System hier ein Problem. Das würde ich erst mal anglisieren bevor ich mit der Keule Reinstall drauf los gehe.

Google mal nach "msi cleanup" oder nach "msicuu2.exe" da wir Dir geholfen.
Sicher ... ist schon dumm dass man das ÜBERHAUPT machen muß, aber das von Dir geschilderte Problem ist weder typisch noch häufig. Und wenn so etwas passiert dann würden bei mir alle Alarmglocken losgehen, da ist dann wohl schon was ober faul am System.

Natürlich spielt immer eine Rolle, wer jetzt genau die MSI gemacht hat, aber da gibt es wahrscheinlich einfach nicht genügend qualifizierte Leute.

Wohl wahr, gut gebrüllt Löwe. Aber kann man das der Technologie anlasten? Ich denke nicht, das machst Du aber (und manch anderer auch).




Uff ... auch hier möchte ich sagen: Nichts für ungut.

Und was ich echt irre finde: Das Thema MSI scheint hier ein echt emotionales zu sein. Warum denn? Sooo viele MS Gegner!

Das kann ja nun jeder halten wie er will, aber was ich mich immer wieder frage:

==> MS-Hasser: Warum setzt ihr denn MS Betriebssysteme und Programme ein? Warum nicht Linux? Oder MAC?



vg,
Hans

[Lefteous]

2habi

Und was ich echt irre finde: Das Thema MSI scheint hier ein echt emotionales zu sein. Warum denn? Sooo viele MS Gegner!

Aus meiner Sicht ist dies in schlechten Erfahrungen mit Setup-Programmen auf MSI-Basis zu erklären. Das ist auch der Grund für die besonders emotionale Diskussion.
Meine persönliche Horrorstory istr eine ältere Visio Version. Hier meldete sich nach abgeschlossener Installation beim ersten Programmstart regelmäßig der MSI zu Wort, dass er noch etwas umkonfigurieren muss. Das kam allerdings nicht nur beim ersten Mal sondern solange bis beim MSi im richtigen Moment den richtigen Knopf gedrückt hat. Ich weiß es nicht mehr so genau - solche Erfahrungen versuche ich zu verdrängen - MSI als Name einer Technologie blieb hängen.
Natürlich könnte man argumentieren, dass Bugs in MSI-Packages nicht gemacht werden müssen. Aber wenn selbst Microsoft dass nicht schafft, wirft das eben ein schlechtes Licht auf die Technologie.

Ich bin sicher nicht der einzige, der solche Geschichten erzählen kann...



Es geht gar nicht so sehr um die Alternativen, sondern um die Schwächen von Windows. Ein Grund für die Beliebtheit des TCs ist dessen Integration in das System. Viele andere Programme gehen hier einen anderen Weg.

Wenn wir schon vom MAC sprechen, Hier gibt es eine Technologie, bei der man auf ein Installationsimage klickt und es dann auf den Programm-Ordner. In anderen Worten: Hier wird ausschließlich kopiert. Das nenne ich Systemintegration.
Es darf natürlich nicht unerwähnt bleiben, dass es hier auch noch eine andere Technologie gibt, mit denen komplexere Setups ausgeführt werden können. Hier entstehen dann wieder die gleichen konzeptionellen Probleme wie unter Windows.

[habi]

@ klsgfx

Das ist jetzt mal ein wirklich sehr guter Hinweis!!

Du kennst mich nicht, Du kannst mir nicht trauen, oder solltest es zumindest nicht .

Aber was ist mit den ganzen Plugins die es für den TCM gibt, weiß Du vorher immer was passiert? Und was ist mit all den Share- und FreeWare Programmen, die Du vermutlich schon in Deinem Leben installiert hast?

Tatsächlich kann es nur mein Bestreben sein, mein MSI so gut und ordentlich zu bauen, wie es meine knappe Zeit zuläßt ... man trifft sich immer zweimal im Leben!

Es sei denn ich wäre ein Böser ... bin ich aber nicht .


Allerdings kann es natürlich immer passieren, dass in dem Setup irgend ein Bug ist, der mir bei keinem meiner Tests aufgefallen ist. Wie unterschiedlich die Systeme im freien Feld sein können kann sich wohl jeder vorstellen!

Insofern macht es wenig Sinn, Installationsprobleme des MSIs an Herrn Ghisler zu melden.

Wenn es trotz ordnungemäßer Installation zu Anwendungsproblemen kommt, dann würde ich das MSI einfach mal deinstallieren und das originale .EXE Setup ausführen. Ist das Problem jetzt weg, dann hat mein Setup wohl irgend etwas falsch gemacht.
Besteht das Problem immer noch, dann ist es sicher legitim, hier im Forum mal nachzuforschen, denn dann handelt es sich wohl sehr wahrscheinlich um einen Programmfehler.

Wenn der Verdacht besteht, dass mein Setup nicht ordnungsgemäß funktioniert, dann bitte eine Nachricht an mich.

Aber in jedem Fall gilt: Wer das von mir erstellte MSI einsetzt tut das natürlich auf eigenes Risiko!

Wobei ich nichts anderes mache, als per MSI Technologie die entsprechenden TCM Files und RegKeys zu installieren. Wer sich auf svsdownloads.de anmeldet kann sich auch die Entwicklungs-Dateien herunter laden (dazu braucht man aber Tools von Wise).

Da ich nicht jeden Tag nachschaue, ob es eine neue Version oder einen BugFix des TCM gibt freue ich mich über einen entsprechenden frühzeitigen Hinweis. Und selbst dann hängt es von meiner Zeit ab, ob und wann ich die nächste Version als MSI fertigstellen kann.



Apropos PlugIns:
Ein Mehrwert des MSI Setups könnte z.B. werden, dass ich in das MSI populäre TCM PlugIns so implementiere, dass Sie direkt als entsprechendes Feature bei der Installation mitausgewählt werden können.


vg,
Hans

[habi]

@Lefteous
Diese schlechten Erfahrungen haben wir alle gemacht.

Und dass da manchmal (oder vielleicht auch öfter mal) echt nervige und unnötige Dinge in Bezug auf MSI Setups passieren ist ebenso nervend wie unnötig.

Insofern sitzen wir doch bei diesen Problemen alle im selben Boot, da geht es mir doch auch nicht anders.

Aber erstens: Deswegen kann ich doch nicht grundsätzlich eine ganze Technologie so mal ganz pauschal ans Kreuz nageln.

Zweitens: Ist denn die .EXE Installations-Technologie wirklich grundsätzlich besser???? Ich glaube nicht!

Woher kommt denn die berüchtigte DLL-Hell?


Es kommt sicherlich nicht von Ungefähr, dass sich anfangen neue Installationstechnologien zu etablieren: Anwendungs-Virtualisierung.

Ich persönlich bin ein Freund von SVS, oder wie es sich jetzt nennt: SWV - Symantec Workspace Virtualization. Deshalb betreibe ich auch die svsdownloads.de Seite. Wenn man mal ein SVS Paket gemacht hat (was super einfach ist - bis zu einem gewissen Grad, wie immer halt), dann kann man dieses exportieren (= als externe zip-kompatible (!) .vsa Datei speichern), und auf einem anderen Rechner wieder importieren.

Und dieses Importieren ist im Wesentlichen ein Extrahieren der .vsa Datei in das Basis-System, ein Entzippen eben! Das ist elegant, schnell und unkompliziert!

SWV ist übrigens kostenfrei für den privaten Einsatz. Ich kann jedem nur raten mal wenigstens einen Blick drauf zu werfen. Gucken kostet nix.




vg,
Hans