Was sind die Vorteile der Verwendung von .msi-Dateien gegenüber regulären setup.exe-Dateien?

Ich habe den Eindruck, dass die Bereitstellung auf Computern einfacher ist, auf denen Benutzer nur über wenige Berechtigungen verfügen, sich jedoch hinsichtlich der Details nicht sicher sind.

Welche Funktionen von msiexec.exe machen die Bereitstellung einfacher als die Verwendung von setup.exe-Szenarien?

Tipps oder Tricks beim Bereitstellen von MSI-Anwendungen?

Nur ein paar Vorteile:

• Kann beworben werden (so dass bei Bedarf eine Installation stattfinden kann).
• Funktionen können wie Werbung installiert werden, sobald der Benutzer versucht, sie zu verwenden.
• Die Statusverwaltung wird beibehalten, sodass Administratoren mit Windows Installer feststellen können, ob eine Anwendung auf einem Computer installiert ist.
• Möglichkeit zum Rollback, wenn eine Installation fehlschlägt.

Ich denke, wenn ich Software in einem Unternehmen bereitstelle: Die Bereitstellung von Software über MSI macht fast Spaß. Im Gegensatz dazu fürchte ich mich fast immer davor, Software bereitzustellen, wenn sie sich in einem anderen Container befindet.

Weitere Informationen zum Bearbeiten von MSI-Installationen finden Sie msiexecim Dialogfeld Ausführen.

UPDATE, Juli 2018 : Eine extrem komprimierte Zusammenfassung der folgenden Informationen zum Stackoverflow ist verfügbar: Die Hauptvorteile von MSI ( sozusagen "executive summary").

Ich habe in der Entwicklung als Release Manager , Build Engineer , Setup Developer sowie als Application Packager und Deployment Engineer in großen Unternehmen gearbeitet.

Dies ist eine Übersicht über die besten (und schlechtesten) konzeptionellen und realen Funktionen von MSI. Die häufigsten Entwurfsprobleme in MSI-Dateien werden nachstehend als separate Antwort aufgeführt . Nicht vorgeben, vollständig zu sein - wirklich nur ein unordentlicher "Brain Dump" - als "das Zeug, das in Büchern nicht zu finden ist" gedacht (wahrscheinlich aus gutem Grund).

Ich möchte auch diesen MSDN-Artikel als gute Lektüre vorschlagen : Windows Installer: Vorteile und Implementierung für Systemadministratoren .

Standardisierung:

Mit einem Wort, bei MSI geht es um Standardisierung und um den Umgang mit " Bereitstellungsgerüchen " von älteren Installer-Technologien. Eine ganze Reihe von Designs für schlechte Installationsarchitekturen, die zu wiederholten Bereitstellungsproblemen führten.

Insgesamt bietet MSI ein umfassendes, standardisiertes Framework für den Installer, das auch die Deinstallations- und integrierten Funktionen und Optionen für den unbeaufsichtigten Betrieb mit standardisierter GUI umfasst , die remote ausgelöst werden können .

Alleine diese Funktionen stellen eine massive Verbesserung gegenüber früheren Installationstechnologien dar, bei denen Deinstallation und unbeabsichtigtes Ausführen zufällig behandelt wurden - möglicherweise die wichtigsten Funktionen für die Unternehmensbereitstellung zusammen mit einer zuverlässigen Remotepaketverwaltung über Active Directory oder dedizierte Remoteverwaltungstools wie Microsoft SCCM (ehemals SMS). IBM Tivoli , CA Unicenter und ähnliche.

Jemand hat eine frühere Version dieser Antwort dupliziert . Vielleicht eine schnellere Lektüre?

Ältere Installationsprogramme "Deployment Smells"

MSI rät von vornherein von Gerüchen bei der Bereitstellung älterer Produkte ab. Diese Themen werden in späteren Abschnitten behandelt. Als kurze Auflistung wurden jedoch die bekanntesten Probleme mit älteren Installationsprogrammen und älteren Bereitstellungstechnologien aufgeführt:

• 1) Sie haben manchmal freigegebene und versionierte Dateien mit geringer Sorge um die daraus resultierende DLL-Hölle heruntergestuft und überschrieben
• 2) Im Lieferumfang des Installationsprogramms war häufig keine ordnungsgemäße Deinstallationsroutine enthalten , oder es wurde nicht ordnungsgemäß und zuverlässig ausgeführt - insbesondere, wenn es im Hintergrund ausgeführt wird. Dies ist ein sehr großes Problem für das SOE-Management von Unternehmen
• 3) Die unbeaufsichtigte Installation wurde selten richtig unterstützt. Die Zuverlässigkeit war schlecht, und man musste häufig einen Durchlauf der Installation mit einer Dialogauswahl aufzeichnen, was bei unerwarteten Bedingungen wie Fehlerdialogen oder Warndialogen, die im ursprünglichen Durchlauf nicht aufgezeichnet wurden, nicht gut war
• 4) Das Installationsprogramm zeichnete nicht auf, was installiert wurde, und daher gab es keine automatische Möglichkeit, Dateien auf der Festplatte zu überprüfen, um zu überprüfen, ob es sich noch um die vom Installationsprogramm ursprünglich installierten Versionen handelte
• 5) Sie enthielten unvorhersehbare, unzuverlässige und nicht standardmäßige Befehlszeilenparameter für die ausführbare Installationsdatei
• 6) Aufgrund der nicht standardmäßigen Befehlszeile und des Fehlens von Standards war es schwierig, Installationsprogramme mit bestimmten Werten, die für die Unternehmensbereitstellung erforderlich sind, zuverlässig und vorhersehbar anzupassen
• 7) Normale Benutzer konnten diese Installationen nicht ausführen, und man musste oft mit temporären Administratorrechten herumspielen (verwenden Sie "Ausführen als", wenn dies ausreicht, oder melden Sie sich als Administrator an, installieren Sie und melden Sie sich dann ab - diese vollständige Anmeldung und Profilerstellung wurde manchmal für den Abschluss der Installation benötigt)
• 8) das setup.exe Installationsprogramm würde oft kein richtigen Fehlercode zurück oder Erfolgscode, und manchmal wäre es sofort beenden und schlägt den Ball von einem anderen Prozess, der die Installation macht es schwierig , zu bestimmen , ob die Installation abgeschlossen wurde beenden würde - vor allem über eine Batch Datei
• 9) Die meisten setup.exe-Dateien ermöglichten das Extrahieren von Dateien, jedoch nicht auf zuverlässige, vorhersehbare Weise. Im Allgemeinen musste viel Zeit darauf verwendet werden, die richtigen Schalter zu finden, um dies zu erreichen
• 10) Die Protokollierung war im Allgemeinen schlecht und bei einigen Tools eher zufällig. Das Debuggen mit Protokolldateien brachte selten Klarheit, half aber ein bisschen
• 11) Es gab keine Transparenz darüber, was das Installationsprogramm tat, und es gab kein oder ein unzuverlässiges Rollback , um Änderungen nach einer fehlgeschlagenen Installation rückgängig zu machen
• 12) Es gab keine branchenübliche Methode zum Bereitstellen gemeinsam genutzter Laufzeitkomponenten, unabhängig davon, ob es sich um Betriebssystemkomponenten, Komponenten von Drittanbietern oder Ihre eigenen handelte

Die Liste enthält eine Reihe weiterer kritischer und anerkannter Bereitstellungsfehler . In der Welt der Unternehmensbereitstellung traten diese Probleme offensichtlich am häufigsten auf und führten zu dem Geschäft des " erneuten Packens von Anwendungen ", bei dem ein älteres Installationsprogramm mit Datenträger- und Registrierungsscantechnologien erfasst wird , um eine standardkonforme MSI-Datei zu erstellen für einen zuverlässigen Einsatz.

Das erneute Packen von Anwendungen ist eine Spezialaufgabe und führt im Allgemeinen zu MSI-Dateien von ausgezeichneter Qualität, wenn dies von sachkundigen Personen durchgeführt wird. Aufgrund der komplexen Registrierungslogik, die interaktiv ausgeführt werden muss, damit bestimmte Anwendungen funktionieren, ist es jedoch nicht möglich, alle Anwendungen erneut zu packen.

Vorteile von MSI - Kurze Zusammenfassung

Im Klartext sind die wirklich wichtigen Vorteile von MSI (in keiner bestimmten Reihenfolge):

• 1) Die Deinstallation ist immer für jedes Paket verfügbar, es sei denn, es ist aktiv deaktiviert
• 2) Dies gilt auch für die Protokollierung , die zwar umfangreich und standardisiert ist, aber ausführlich ist (Tools wie WiLogUtl.exe können zum Analysieren der Protokolldateien verwendet werden).
• 3) Was eine MSI-Datei tut, ist größtenteils (halb-) transparent oder "überprüfbar". Die Ausnahme sind benutzerdefinierte Aktionen - (siehe Abschnitt Transparenz unten)
• 4) Setup-Anpassung erfolgt auf standardisierte Weise ( Transformationen )
• 5) Es ist nicht erforderlich, sich mit temporären Administratorrechten herumzuschlagen, da die Installation über Active Directory-Ankündigung, Gruppenrichtlinien oder Remoteverwaltung ausgeführt wird. Einige Qualifikationen hier. Siehe auch diesen Screenshot aus dem Gruppenrichtlinienobjekt-Editor.
• 6) Die automatische Installation / Deinstallation über Verwaltungstools oder die Verwendung von msiexec.exe funktioniert einwandfrei
• 7) Es gibt vollständige Rollback- Unterstützung für fehlgeschlagene Installationen. Wenn Sie die Box manuell installieren, müssen Sie einige Qualifikationen kennen.
• 8) Die MSI-Datei eignet sich sowohl zur Überprüfung als auch zur Validierung auf Konsistenz und logische Gültigkeit, da sie einem Datenbankschema entspricht ( siehe Validierungsbeispiel ).
• 9) Aktualisierungen sind standardisierte Typen, obwohl sie für unerfahrene Paketierer komplex und häufig fehleranfällig sind
• 10) das extrahieren von dateien aus der msi ist eine integrierte funktion (siehe verlinkten artikel für einen guten schnellen überblick)
• 11) Die Windows Installer-Befehlszeile, msiexec.exe , bietet eine sehr genaue Kontrolle darüber, wie die Installationssequenz ausgeführt werden soll, und alle Optionen funktionieren mit allen standardkonformen MSI-Dateien (Protokollebene festlegen, unbeaufsichtigt / interaktiv / halb unbeaufsichtigt ausführen) , Installationsparameter einstellen, Transformationen anwenden etc ...).
• 12) Merge-Module ist der MSI-Mechanismus zum Bereitstellen gemeinsam genutzter Dateien mit mehreren MSI-Paketen. Es handelt sich um ein Verbrauchsmaterialmodul oder ein Paket mit Installationslogik, das zur Kompilierungszeit mit jedem MSI-Paket zusammengeführt werden kann. Wix hat dieses Konzept durch die Verwendung von Wix-Include-Dateien erweitert und verbessert - ein Konzept, das meiner Meinung nach den Zusammenführungsmodulen überlegen ist - insbesondere für Ihre eigenen Dateien (dh keine Betriebssystemdateien).
• 13) Die Windows Installer-Engine selbst verfügt über einen Mechanismus, der verhindert , dass versionierte oder geänderte Dateien bei der Installation überschrieben werden . Dies wird durch eine recht komplexe Dateiersetzungslogik gesteuert . Obwohl effizient und gut, kann die Logik ein Problem für sich sein, da viele Entwickler das Problem haben, dass sie ihre geänderten Konfigurationsdateien beim Upgrade nicht überschreiben können. Die Lösung für diese Probleme sind im Allgemeinen geringfügige Änderungen im Anwendungsdesign, um häufige Anti-Patterns für die Bereitstellung zu vermeiden. Dies ist jedoch eine große eigene Diskussion.

In der realen Welt habe ich weniger erfolgreiche Aspekte festgestellt , darunter das Patchen (sehr komplex), MSI-GUI (einfache Funktionen, ziemlich komplex, mangelnde Flexibilität), Ausfallsicherheit (kann das Debuggen sich wiederholender Selbstreparaturprobleme erschweren ) und die Gesamtkomplexität Umgang mit der Technologie für Anfänger (hohe Komplexität der Grundoperationen zuweilen - zum Beispiel Upgrades, GUI und die vielen interagierenden Details verursachen unerwartete Ergebnisse usw.). Die Geschwindigkeit des Installationsprozesses hat sich aufgrund des erhöhten Overheads von MSI ebenfalls erheblich verlangsamt. Beachten Sie einige Tipps zur Verbesserung der MSI-Installationsgeschwindigkeit .

Der Rest des Textes befasst sich ausführlicher mit einigen dieser Aspekte von MSI.

Transparenz (offenes Installer-Format)

Eine MSI-Datei ist im Wesentlichen eine reduzierte SQL Server-Datenbank, die als COM-strukturierte Speicherdatei gespeichert ist - im Wesentlichen ein Dateisystem in einer Datei oder einer Sammlung von Datenströmen. Dieser Dateityp wird in Microsoft Office-Dokumenten verwendet und bietet ein Standardformat , das überprüft und überprüft werden kann - ein großes Problem für große Unternehmen.

Mit Ausnahme der kompilierten benutzerdefinierten Aktionen ist eine MSI-Datei ein weißes Kästchen . Wenn das Setup verrückte Änderungen wie die systemweiten Netzwerkeinstellungen vornimmt, können Sie diese mithilfe der entsprechenden Tools anzeigen . Die bemerkenswerte Ausnahme sind kompilierte benutzerdefinierte Aktionen - die Blackbox sind . Für Windows-Logo-Anforderungen müssen benutzerdefinierte Aktionen mit Anmerkungen versehen werden, um zu erläutern, was sie tun. Dies wird jedoch von Setup-Entwicklern häufig ignoriert. Hoffentlich verbessert das Aufkommen von Wix dies.

Um festzustellen, was solche kompilierten benutzerdefinierten Aktionen im technischen Sinne tatsächlich tun, ist eine Setup-Erfassung erforderlich. Dies wird meiner Erfahrung nach kaum jemals gemacht. Es ist üblicher, sich an den Hersteller zu wenden, um Informationen zu erhalten, wenn die Software für die Unternehmensbereitstellung genehmigt werden muss. In diesem Fall ist es möglicherweise die Anwendung selbst, die die Verwendung verhindert, und nicht nur das Setup.

Anpassbarkeit (Transformationen)

Ein MSI kann über Transformationen an die Anforderungen und Standards eines Unternehmens angepasst werden, wobei die Interoperabilität mit den Installationsupdates des Herstellers erhalten bleibt. Sie ändern das Installationsprogramm nicht selbst, sondern erstellen Ihre Anpassung in einer separaten, organisationsspezifischen Datei, der Transformation (.mst-Datei) (ein Datenbankfragment oder eine Änderungstransaktion, wenn Sie möchten ). Es steht Ihnen frei, benutzerdefinierte Aktionen zu deaktivieren und im Allgemeinen alles im Installationsprogramm zu ändern, zu überschreiben oder zu deaktivieren. Sie können sogar neue Dinge, einschließlich Dateien, hinzufügen. Die Transformationsdateien werden manchmal auch verwendet, um eine MSI-Datei in verschiedene Sprachen zu lokalisieren. Auf eine MSI können mehrere Transformationen angewendet werden. Hier ein Beispiel mit abgeschnittenen Pfaden :

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Schnelle Parametererklärung:

/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.

Management und Berichterstattung

Windows Installer verwaltet eine umfassende Datenbank aller Elemente, die ein Produkt in der Registrierung installiert hat ( HKEY_CLASSES_ROOT \ Installer - ändern Sie hier niemals etwas direkt! Dies gilt auch für Experten).

Sie können zuverlässig feststellen, ob ein Produkt installiert ist, welche Funktionen installiert wurden und welche Dateiversionen installiert wurden. Darüber hinaus erhalten Sie eine Liste aller Patches, die auf das Basisprodukt angewendet wurden, sofern vorhanden. Sie können über APIs, die Win32, COM oder .NET unterstützen, auf diese Datenbank zugreifen, indem Sie verschiedene Skript-, Konfigurations- und Verwaltungstools wie Microsoft SCCM , IBM Tivoli , CA Unicenter usw. verwenden.

Sicherheit (vorübergehend erhöhte Rechte)

MSI umfasst auch Prinzipien für "erhöhte Rechte", die es einem eingeschränkten Benutzer ermöglichen, die Installation eines Produkts auszulösen, für dessen Installation Administratorrechte erforderlich sind. Dies ist Teil der " Ankündigungsfunktion ", mit der ein Administrator den Benutzern Installationsprogramme zur Verfügung stellen kann, ohne sie tatsächlich auf allen Arbeitsstationen zu installieren. Das Installationsprogramm selbst muss auf mehreren Hauptkonten ordnungsgemäß erstellt worden sein, damit dieses Konzept mit erhöhten Rechten ordnungsgemäß funktioniert. Die Benutzer können die Installation des Produkts selbst auslösen oder die Installation wird von einem dedizierten Bereitstellungssystem wie SCCM, Tivoli, Unicenter (normalerweise größere Unternehmen) gesteuert. Es ist nicht erforderlich, sich mit temporären Administratorrechten herumzuschlagen , um die Arbeit zu starten Dies ist häufig bei älteren Installateuren der Fall.

Die umfassende Installationsdatenbank stellt außerdem sicher, dass Sie einen vollständigen Überblick über die installierten Patches haben und somit Sicherheitslücken über Automatisierungs- und Verwaltungstools erkennen können.

Validierung

MSI-Dateien können mit Validierungsregeln überprüft werden, um sicherzustellen, dass sie einer Reihe interner Konsistenzregeln ( ICE) entsprechen). Unternehmen können ihre eigenen ICE-Prüfungen erstellen, um spezielle Unternehmensregeln und -anforderungen durchzusetzen. Dies hilft sehr bei der Qualitätssicherung. Der Grund für die mögliche Validierung liegt in der Selbstreferenzierung relationaler Datenbanken und dem zugehörigen Datenbankschema. Die Datenbank muss intern konsistent sein und in Bezug auf Fremdschlüssel, Datentypen, Feldbreite, Schemaversion usw. ihrem eigenen Schema entsprechen. Die Validierung geht auch darüber hinaus und kann echte logische Fehler und Fehler im Paket erkennen , nicht nur Formatierungs- und Tippfehler. Beispielsweise kann es Dateien oder Dateitypen erkennen, die an fehlerhaften Zielorten bereitgestellt werden.

Ausfallsicherheit (Selbstreparatur)

Die Administrator-Installationsfunktion von Windows Installer bietet eine Standardmethode zum Extrahieren der Quelldateien von einer MSI ( hier finden Sie einige zusätzliche Informationen zu diesem Thema ). Diese Quelldateien können dann auf einer Freigabe abgelegt werden und stehen allen Arbeitsstationen zur Installation zur Verfügung. Auf diese Weise wird sichergestellt, dass Reparatur-, Deinstallations- und Änderungsvorgänge abgeschlossen sind, ohne dass Sie das Installationsmedium auf CD oder Ähnlichem anfordern müssen. Dies ist besonders wichtig für Patch- und Aktualisierungsvorgänge, bei denen unter bestimmten Umständen auf die Quelldateien der alten Versionen zugegriffen werden muss.

Es gibt auch häufige Probleme mit dieser Ausfallsicherheitsfunktion. Die meisten Administratoren haben Maschinen mit zyklischen Selbstreparaturzyklen erlebt , die nie anzuhalten scheinen. Folgen Sie dem Link, um eine lange Liste der Ursachen für dieses Problem zu erhalten. Und noch einmal, hier ist eine kürzere Version , die möglicherweise leichter zu lesen ist.

Rollback

Die Installation einer MSI-Datei löst normalerweise die Erstellung eines Wiederherstellungspunkts aus . Darüber hinaus werden alle Dateien und Registrierungselemente, die während der Installation ersetzt oder überschrieben wurden, gespeichert und wiederhergestellt, wenn die Installation nicht abgeschlossen werden kann. Änderungen an benutzerdefinierten Aktionen bleiben vorbehalten.

Benutzerdefinierte Aktionen müssen eine eigene Rollback-Unterstützung für die Einhaltung des Windows-Logos implementieren. Dies wird häufig ignoriert, erfordert jedoch das Erstellen einer zweiten benutzerdefinierten Aktion, um die von der benutzerdefinierten Hauptaktion vorgenommenen Änderungen rückgängig zu machen.

Das Rollback stellt sicher, dass die Workstation in einem stabilen Zustand bleibt, selbst wenn die Installation fehlschlägt. Das eigentliche Rollback-Skript wird in einem versteckten Ordner direkt auf dem Systemlaufwerk gespeichert - in der Regel C: \ Config.MSI . Es enthält Dateien mit den Erweiterungen .RBS und .RBF - Rollback- Skriptdateien . Wie Sie vielleicht erwarten können, verletzen schlecht gestaltete MSI-Dateien hier die integrierten Funktionen von Windows. Weitere Informationen finden Sie in meinem anderen Beitrag in diesem Thread.

Es gibt Möglichkeiten, das Rollback zu deaktivieren und die Installation zu beschleunigen. Nicht generell empfohlen, aber hier finden Sie Details zur MSIFASTINSTALL-Eigenschaft und zu DISABLEROLLBACK . Dies ist eine komplizierte Funktion, aber hier ist eine kurze Übersicht über das Rollback .

Patches und Updates

Obwohl das Patchen in Windows Installer sehr komplex ist, wird es vollständig verwaltet und auf dem System registriert, sodass ein Systemsicherheitsstatus durch Überprüfen der installierten Komponenten ermittelt werden kann. Aktualisierungen sind auf einige grundlegende Varianten standardisiert. Dadurch können Aktualisierungen mit einem höheren Maß an Sicherheit durchgeführt werden, sofern Sie mit der damit verbundenen Komplexität fertig werden. Bereitstellungssysteme können melden, welche Aktualisierungen fehlgeschlagen sind und warum.

Aus subjektiver Sicht eignet sich das Patchen für zwei grundlegende Zwecke : 1 ) kleine Hotfixes für gelieferte Produkte und 2 ) das Patchen eines installierten Produkts, um die fehlerhafte Deinstallationssequenz zu beheben, die eine saubere Deinstallation der Produkte verhindert.

Ein Patch ist nur ein Übermittlungsmechanismus für ein Update, das bereits funktioniert . Als solches ist es nur ein Container, der komplizierter und fehleranfälliger ist als das ursprüngliche Setup. Die wichtigste Regel für einen Patch ist, dass er kleiner sein muss als die ursprüngliche MSI, oder es gibt keinen offensichtlichen Grund, überhaupt einen Patch bereitzustellen. Ein Patch kann schnell riesig werden, wenn er auf mehrere Produktversionen abzielt.

Protokollierung (in der Tat ausführlich)

Windows Installer bietet eine standardisierte Protokollierungsfunktion, die früheren Inkarnationen weit überlegen ist, wenn auch fast übermäßig ausführlich. Protokolldateien können mithilfe von Protokollanalysegeräten entschlüsselt werden , und benutzerdefinierte Protokollstufen können verwendet werden, um zu verhindern, dass zu große Protokolldateien mit unnötigen Informationen erstellt werden. Für Debugging-Zwecke ist die ausführliche Protokollierung äußerst nützlich. Siehe Rob Mensching Blog für eine gute manuelle Art und Weise einer MSI - Protokolldatei zu lesen ( im Wesentlichen suchen Sie nach „ Wert 3 “ in der Protokolldatei). Hier ist eine Beispielbefehlszeile, die eine ausführliche Protokollierung durchführt:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

Dieser Artikel von Robert Macdonald vom Windows Installer-Team wird dringend empfohlen, um einen praktischen Einblick in die MSI-Protokollierung zu erhalten: Interpretieren von Windows Installer-Protokollen .

Fazit

Nicht alles ist gut über Windows Installer . Die Komplexität kann manchmal verwirrend sein, aber für große Unternehmen sind MSI-Dateien jeder anderen Form der Bereitstellung weit überlegen, wenn Sie die oben aufgeführten Vorteile berücksichtigen.

Neues Installer-Paradigma (die riesige SQL-Anweisung)

Um das neue " Paradigma " zu verstehen, ist es wichtig zu verstehen, dass MSI eher eine deklarative Beschreibung dessen ist, was auf dem Zielsystem passieren wird, als eine feste Abfolge von Ereignissen. Ich nehme an, Sie können sich das als eine riesige SQL-Anweisung vorstellen . Beispielsweise deklarieren Sie Elemente, die einer INI-Datei hinzugefügt oder geändert werden sollen. Während der Installation werden Änderungen nachverfolgt und ein Rollback ist verfügbar, sodass Änderungen zurückgesetzt werden können, wenn die Installation fehlschlägt. Dies funktioniert wirklich wie " automagisch " und ist zuverlässig, wenn es richtig gemacht wird.

Benutzerdefinierte Aktionen (die üblichen Verdächtigen)

Es ist ein großen Kopfschmerzen für erfahrene MSI Entwickler Menschen auf komplexe, unzuverlässig benutzerdefinierte Aktionen für Funktionalität verlassen , um zu sehen , die besser mit eingebauten in MSI - Funktionen implementiert. Ein erheblicher Teil aller MSI-Fehler und Rollback-Probleme wird durch fehlerhafte benutzerdefinierte Aktionen verursacht, und die meisten anderen Fehler werden durch fehlerhafte Verwendung des MSI-Designs verursacht (eine Liste der häufigsten MSI-Fehler finden Sie in der separaten Antwort).

Zusätzlich zu den integrierten MSI-Funktionen stehen über ein neues Framework wie Wix - die XML-Methode zum Kompilieren von MSI-Dateien - immer mehr benutzerdefinierte Funktionen zur Verfügung , sodass für die meisten Vorgänge immer weniger komplexe benutzerdefinierte Aktionslogiken erforderlich sind.

MSI bietet vollständige Unterstützung für das Zusammenführen von INI-Dateieinstellungen, Schriftarten, Umgebungsvariablen, Registrierungsschlüsseln, COM-Informationen, Verknüpfungen, Dateierweiterungen, Startbedingungen, GAC-Installation, ODBC usw.

WIX bietet Unterstützung für erweiterte Funktionen wie SQL Server-Erweiterungen, IIS-Installationen und -Konfiguration, Leistungsindikatoren, DirectX-Prüfung und andere spielbezogene Aufgaben, native .NET-Image-Generierung, COM +, Treiber, Firewall-Regeln, PowerShell-Erweiterungen, Schließen von Anwendungen, Verwaltung von Benutzern, Gruppen, Freigaben und vielem mehr. Etwas umständlich, aber viel zuverlässiger als Ihre eigenen benutzerdefinierten Aktionen.

Vermeiden Sie benutzerdefinierte Aktionen um jeden Preis, wenn möglich

Um es in die richtige Perspektive zu rücken: Diese integrierten und vorgefertigten Lösungen werden von den besten verfügbaren Bereitstellungsexperten erstellt und von Tausenden, Zehntausenden oder vielleicht sogar Millionen von Benutzern (für integrierte Funktionen in MSI) getestet selbst). Glauben Sie wirklich, dass Sie Ihre eigenen benutzerdefinierten Aktionen verbessern können? Die Verwendung einer benutzerdefinierten Aktion sollte ein seltenes Ereignis sein und es sollte unbedingt erforderlich sein, für das von Ihnen installierte Produkt etwas Einzigartiges zu erreichen . Und Sie müssen auch die richtige Rollback-Unterstützung schreiben, was ziemlich kompliziert ist.

Das Schreiben einer benutzerdefinierten Aktion ist fast immer ein Fehler , aber es gibt echte Fälle, in denen Sie die Flexibilität auch wirklich benötigen. Wie immer ist es wichtig, dass Sie Ihre Schlachten gut auswählen. Es mag zunächst eine lustige Aufgabe sein, aber Sie werden wahrscheinlich mit vielen unerwarteten Problemen konfrontiert sein und viel kostspielige Zeit verschwenden. Ich meine das sehr ernst. Ich habe eine Reihe von benutzerdefinierten C ++ - Aktionen für den Unternehmensgebrauch selbst geschrieben (um fehleranfällige benutzerdefinierte VBScript-Aktionen zu beseitigen) - es ist kein Kinderspiel, und obwohl die Codierung möglicherweise nicht die schwierigste der Welt ist, ist das Debuggen und Testen und Der Anschluss an eine tatsächliche MSI-Datei ist äußerst aufwändig. Wenn Sie einige Zeit nachprüfen, welche vorgefertigten Optionen verfügbar sind, sparen Sie wahrscheinlich Wochen an Entwicklungsarbeit und erzielen eine wesentlich höhere Zuverlässigkeit der Bereitstellung.

Verwenden Sie die Anwendungsstartsequenz

Ein sehr wichtiger Punkt ist, dass viele Anwendungskonfigurationen beim Start der Anwendung stattfinden sollten, wenn ein vorhersehbarer Laufzeitkontext und eine gute Fehlerbehandlung zur Verfügung stehen, und nicht in dem Setup, das nur einmal ausgeführt wird und über sehr komplizierte Identitätswechsel , Sequenzierung , Konditionierung und Laufzeit verfügt Komplexität .

Ihr Setup sollte die Anwendung nicht konfigurieren, es sollte die Anwendung für die Konfiguration beim ersten Start vorbereiten . Insbesondere sollte Ihr Setup alle Einstellungen schreiben, für die erhöhte Rechte erforderlich sind - Schreiben in HKLM, Registrieren von Diensten, Installieren auf Computerpfaden und alle Dinge, die eine Anwendung mit normalen Benutzerrechten nicht alleine schreiben kann.

Wenn Sie ein Setup-Entwickler sind, sollten Sie anbieten, sich an der Programmierung der Anwendungsstartsequenz zu beteiligen, anstatt benutzerdefinierte Setup-Aktionen zu schreiben . Wenn nichts anderes, um nicht so auszusehen, als würden Sie versuchen, das Geld an jemand anderen weiterzugeben. In dieser Startsequenz können Sie viel zuverlässigeren und überprüfbareren Code schreiben, der es einfacher macht, Hilfe vom QA-Personal zum Testen zu erhalten (sie verstehen häufig nicht das Testen von Bereitstellungen sowie das Testen von Anwendungen).

Einrichtungskomplexität

Der Kern der Komplexität des Setups liegt in der Tatsache, dass Fehler kumulativ sind (Sie verwalten einen Übermittlungsprozess, nicht nur eine schnelle Neukompilierung), Fehler nur sehr schwer zu debuggen sind (kein Zugriff auf die Systeme, auf denen die Fehler auftreten) und auf das Zielsystem Zustände unterscheiden sich in fast jeder erdenklichen Weise . In dieser Antwort erfahren Sie mehr über diese Komplexität und wie sich Zielsysteme auf schockierende Weise verhalten können: Windows Installer und die Erstellung von WiX sowie die Komplexität der Bereitstellung (siehe unten).

WiX (beste MSI-Lösung für einige Zwecke)

In dieser WiX-Kurzanleitung finden Sie eine Beschreibung der neuen XML-basierten Methode zum Kompilieren von MSI-Dateien. Die textbasierten Quelldateien bieten eine viel bessere Quellcodeverwaltung als zuvor. Dies ist ein kostenloses Open-Source-Toolkit, das dringend empfohlen wird .

NB : An anderer Stelle im Thread finden Sie eine kurze Übersicht über die häufigsten Entwurfsprobleme bei MSI-Dateien. Diese sind sehr unvollständig, sollten aber unbedingt gelesen werden. Ich wollte das nicht zu dieser Antwort hinzufügen, da es nicht zu 100% verwandt ist, aber für den realen Gebrauch ist es ein entscheidendes Thema.

Einige grundlegende MSI-Informationen für Systemadministratoren:

(Entschuldigen Sie die schamlose "Beförderung" - es ist für den einfachen Zugang und Abruf)

Hier nur einige Links zu Themen, die für Systemadministratoren hilfreich sein können, um die Bereitstellung in ihren Netzwerken zu steuern:

• Wie kann ich die großen zwischengespeicherten MSI-Dateien in C: \ Windows \ Installer entfernen? (hohe Festplattennutzung durch MSI)
• So beschleunigen Sie MSI-Installationen (nur einige Optionen)
• So extrahieren Sie Dateien aus setup.exe (lesenswert für jeden Administrator, wahrscheinlich alte Nachrichten)
• Verschiedene Möglichkeiten zum Deinstallieren einer MSI (Deinstallationsreferenz, beliebt - hohe Anzahl von Ansichten)
• So umgehen Sie msiexec.exe beim Umgang mit MSI-Paketen (MSI-Automatisierung und -Skripting)
• Warum benötigt MSI die Original-MSI-Datei, um mit der Deinstallation fortzufahren? (häufige Frage)
• Warum enthält die Prozessliste während der Installation mehrere msiexec.exe-Prozesse? Was machen sie alle?

Spezielle Themen zur Vorgehensweise:

• Erzwingen eines Upgrades einer Datei, die während der Erstinstallation geändert wurde (häufig gestellte Frage)
• Gibt es trotzdem zu bekommen msiexec Echo statt Protokollierung in eine Datei stdout (fortgeschrittenes Thema, mit externer gui für MSI, mehr EntwicklerGehalt)
• Ich möchte ein MSI zweimal installieren (Instanz transformiert oder virtualisieren - im Ernst :-)).
• So aktualisieren Sie jedes Benutzerprofil mit ActiveSetup (etwas gefährlich, aber nützlich)
• Häufige Fehler in MSI-Paketen (eher für Entwickler, aber auch für Systemadministratoren)
• Debuggen der zyklischen Selbstreparatur (wichtiges Thema)

Konzeptionelle Themen / Best Practice:

• Was ist der Nutzen und der eigentliche Zweck der Programminstallation? (Grundlagen der Bereitstellung)
• Zweck von Administratorinstallationen (MSI-Kernoperation für Systemadministratoren)
• Warum sollten Sie MSI nicht für Registry-Optimierungen verwenden (empfohlene Lektüre)
• Welches Installationsprodukt soll verwendet werden? (Stärken und Schwächen verschiedener Werkzeuge)
• Warum Selbstregistrierung bei MSI als schädlich eingestuft wird

Diese Antwort ist sehr viel in Arbeit und eine grobe Gliederung. Ergänzungen, Fragen und Updates sind willkommen. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Fügen Sie einen Kommentar mit Informationen zu problematischen Paketen hinzu.

Typische Probleme und Designfehler in MSI-Paketen

Ich muss auch warnen, dass viele MSI-Dateien Fehler enthalten, manchmal schwerwiegende, aber geschulte Anwendungspaketierer können dies erkennen und in den meisten Fällen das Problem beheben. Ich füge dies als separate Antwort hinzu, da es im Wesentlichen eine andere Frage beantwortet, aber ich denke, dass es im selben Thread relevant ist.

Die technischen Details von MSI sind sehr kompliziert . Auf der Basisebene geht es darum, Ihre Dateien und Registrierungseinstellungen in Komponenten (atomare Installation) und Funktionen (vom Benutzer auswählbare zu installierende Anwendungsteile, z. B. eine Wörterbuchfunktion) zu zerlegen. Es gibt eine Reihe von Best-Practice-Regeln für die Aufteilung der Komponenten, und hier sind zahlreiche Fehler in MSI-Dateien zu finden. Diese Fehler werden im Allgemeinen durch Standardisierung der Verwendung von "Haupt-Upgrades" behoben.

Die eigentliche Installation erfolgt in mehreren Installationssequenzen, teilweise mit erhöhten Rechten . All diese Dinge sind in Datenbanktabellen definiert, und hier ist es fürchterlich kompliziert, MSI zu verstehen und damit umzugehen. Über die Installationssequenzen verteilt sind Standard- und benutzerdefinierte Aktionen. Die Standardaktionen sind von Microsoft entworfen und müssen ausgeführt werden (die Reihenfolge kann manchmal geändert werden). Anbieter können benutzerdefinierte Aktionen ausführen, die nicht von MSI selbst abgedeckt werden. Diese können in Skriptform oder in kompilierter Form vorliegen. Benutzerdefinierte Aktionen können sofort (werden sofort ausgeführt, sollten das System nicht ändern, werden jedoch häufig ausgeführt) oder verzögert (in ein Ausführungsskript geschrieben, das dann als Transaktion ausgeführt wird und daher Rollback unterstützt) werden.

Typische Fehler in einer MSI sind (in keiner bestimmten Reihenfolge - und wirklich als echtes Durcheinander dargestellt):

• Fehler bei der Erstellung der Komponenten (nicht gemäß der bewährten Methode). Dies kann zu Problemen beim Patchen und Upgraden mit mysteriösen Symptomen wie fehlenden Dateien und Einstellungen oder Patches führen, die mit unsinnigen Fehlern bombardiert werden. Zur Vereinfachung sollte eine Datei pro Komponente verwendet werden, es sei denn, die Anzahl der Dateien ist enorm.
• Aktualisierungsprobleme in Bezug auf Benutzerdaten, die überschrieben oder zurückgesetzt werden. Weitere Details finden Sie weiter unten.
• Eine falsche Planung von benutzerdefinierten Aktionen außerhalb des "Transacted Section" der Installationssequenzen oder benutzerdefinierte Aktionen des falschen Typs werden falsch platziert. Dies führt häufig dazu, dass die Aktionen fehlschlagen (keine erhöhten Rechte), wenn sie remote über Bereitstellungssysteme ausgeführt werden, und das Rollback wird effektiv behindert, da nur durchgeführte Aktionen zurückgesetzt werden. Die Windows Installer-Transaktion (think database transaction commit) wird zwischen den Standardaktionen InstallInitialize und InstallFinalize in der Hauptinstallationssequenz ausgeführt und mit erhöhten Rechten ausgeführt . Alle Änderungen am System sollen in dieser Transaktion stattfinden - alles andere ist fehlerhaft (aber leider ziemlich häufig).
• Verwendung von benutzerdefinierten Aktionen im Sofortmodus, um Änderungen am System außerhalb der durchgeführten Installationssequenz vorzunehmen . Dies unterbricht die Rollback-Unterstützung und führt im Allgemeinen zu Sicherheitsfehlern, da benutzerdefinierte Aktionen im Sofortmodus nicht mit erhöhten Benutzerrechten ausgeführt werden, unabhängig davon, wo sie in den Installationssequenzen abgelegt sind.
• fehlerhafte Konstruktionen, die dazu führen, dass sich wiederholende Zyklen der Selbstreparatur ohne offensichtlichen Grund auftreten. Hier ist ein weiterer Artikel zu diesem Thema von installsite.org
• Benutzerdefinierte Aktionen , die die Unterdrückung der grafischen Benutzeroberfläche im unbeaufsichtigten Installationsmodus nicht berücksichtigen, zeigen möglicherweise modale Dialogfelder an, bei denen die Bereitstellung vollständig fehlschlägt, wenn sie unbeaufsichtigt ausgeführt wird. Dieses Problem sowie der allgemeine Unterschied zwischen dem stillen Modus und dem interaktiven Modus werden hier ausführlicher beschrieben (etwas ausführlich und langwierig): Die Deinstallation in der Systemsteuerung unterscheidet sich von der Deinstallation von .msi
• Einige benutzerdefinierte Aktionen in fehlerhaft erstellten Paketen werden nur in der Benutzeroberflächensequenz eingefügt . Dadurch werden sie nicht im unbeaufsichtigten Installationsmodus ausgeführt. Dies ist für die Unternehmensbereitstellung von großer Bedeutung, da hier fast ausschließlich die unbeaufsichtigte Installation verwendet wird. Dieses Problem kann sich auch auf die Deinstallation auswirken, dh, Sie müssen die Deinstallation möglicherweise interaktiv ausführen, um sicherzustellen, dass alle benutzerdefinierten Bereinigungsaktionen ausgeführt werden. Unter dem Link im vorherigen Aufzählungspunkt finden Sie eine ausführlichere Beschreibung der Benutzeroberflächenebenen.
• Das Setup enthält Dateien, die nicht an dem Ort bereitgestellt werden sollen, an dem sie installiert werden. In der Regel Systemdateien, die nebeneinander im WINSXS-Assembly-Ordner installiert werden sollen.
• Langsame Installationsgeschwindigkeit ist ein weiteres "Problem", das viele mit MSI melden. Hier einige Tipps zum Thema . Insgesamt bietet Windows Installer aufgrund der hohen Registrierungsanforderungen in der Registrierung für die zu installierende Software einen erheblichen Overhead.
• Überschreiben von benutzerdefinierten Informationen oder gemeinsam genutzten Datendateien . Dies kann passieren, wenn eine INI-Datei über die File-Tabelle und nicht beispielsweise über die IniFile-Tabelle installiert wird. Im letzteren Fall wird es wie eine "Änderungstransaktion" behandelt, im ersten Fall handelt es sich um eine Dateiersetzungsoperation, die im Allgemeinen falsch ist, es sei denn, Ihre INI-Datei verfügt über nicht standardmäßige Formatierungs- oder große Kommentarbereiche, die Sie mit Ihrer Datei bereitstellen möchten (mit Sicherheit üblich) Entwicklerwerkzeuge).
• Die komplexen Regeln für das Überschreiben von Dateien können dazu führen, dass Dateien unbeabsichtigt überschrieben oder gar nicht aktualisiert werden. Dies ist ein klassisches MSI-Problem. In diesem Artikel erfahren Sie, wie Sie das Überschreiben einer Datei erzwingen können, die nicht aktualisiert wird . Die Regeln können durch benutzerdefinierte Einstellungen für die Eigenschaft REINSTALLMODE, die auf der Befehlszeilenebene msiexec.exe festgelegt ist (Überschreiben älterer Versionen, Überschreiben gleicher Versionen, Überschreiben beliebiger Versionen usw.) , leicht angepasst werden und funktionieren für Datendateien und versionierte Dateien unterschiedlich. Details im SDK . Dies zu verstehen ist entscheidend und es ist ein Design, das oft missbilligt wird, selbst wenn es verstanden wird.
• Die Selbstregistrierung von COM-Dateien während der Installation kann auf verschiedene Weise Sicherheitswarnungen auslösen oder Probleme verursachen. Überprüfen Sie diesen Artikel: Selbstregistrierung als schädlich .
• Eine Variation des Problems des Ersetzens von Dateien ist der Fall, wenn bei einem größeren Upgrade (bei dem das Produkt deinstalliert und erneut installiert wird) geänderte Dateien deinstalliert und die Standardversionen erneut installiert werden. In diesen Fällen sieht der Inhalt zurückgesetzt oder überschrieben aus, wenn er tatsächlich zuerst deinstalliert und dann erneut installiert wurde.
• Dienste, die mit benutzerdefinierten Benutzeranmeldeinformationen ausgeführt werden, verlieren möglicherweise ihre Anmeldeinformationen während umfangreicher Aktualisierungsszenarien und setzen die Einstellungsdatei (anscheinend) auf den Standard zurück (sie wurden wirklich deinstalliert und neu installiert). Nur um es festzuhalten: Meiner Meinung nach ist die Ausführung von Diensten mit Benutzeranmeldeinformationen in erster Linie ein Konstruktionsfehler.
• Öffentliche Eigenschaften werden vom Client nicht ordnungsgemäß an den Serverprozess übergeben, sodass benutzerdefinierte Aktionen nicht wie erwartet ausgeführt werden können. Hierbei wird die SecureCustomActionProperties-Eigenschaft aktualisiert.
• Einige Anwendungen können nicht ordnungsgemäß für andere Benutzer als denjenigen ausgeführt werden, der das Setup ursprünglich installiert hat. Dies ist ein schwerwiegender Entwurfsfehler, der jedoch im Allgemeinen von erfahrenen Anwendungspaketierern mithilfe von Self-Healing oder ActiveSetup behoben werden kann , um HKCU-Registrierungsschlüssel und Benutzerprofildateien hinzuzufügen . Dies ist ein ziemlich komplexes Thema, und es kann ein bisschen schwarze Kunst erfordern, um zu arbeiten. Um es festzuhalten: Meiner Meinung nach besteht die eigentliche Lösung darin, die Anwendung selbst zu ändern, um alle Benutzereinstellungen basierend auf Standardeinstellungen und Vorlagen, die von einem Standort pro Computer kopiert wurden, oder basierend auf internen Standardeinstellungen der Anwendung (von der Quellcode).
• Einige MSI-Dateien beeinträchtigen die Sicherheit für installierte Dateien, indem sie hier, dort und überall vollständige Lese- / Schreibrechte für Nicht-Administratoren festlegen. In anderen Fällen funktioniert die Anwendung aufgrund fehlender Berechtigungen nicht mehr unter neueren Windows-Versionen. Application Packager werden häufig mit der Analyse der benutzerdefinierten Berechtigungsanforderungen einer Anwendung konfrontiert. In der Regel sind in HKLM oder in% ProgramFiles% zusätzliche Berechtigungen erforderlich.
• Einige Installshield- Setups früherer Tage versuchten, während der Installation eine Verbindung zum Internet herzustellen. Dies ist für Bereitstellungsszenarien in Unternehmen schrecklich, in denen die Bereitstellung streng kontrolliert wird und der Installer niemals neue Inhalte direkt aus dem Internet herunterladen darf.
• Ein weiteres Netzwerkproblem ist, wenn Setups versuchen, eine GUI anzuzeigen, in der Benutzer Daten eingeben, die während der Installation über das Internet validiert werden, oder nur Live-Inhalte von ihrer Website anzeigen. Dies sind normalerweise E-Mail-Adressen, Kontaktinformationen, Lizenzschlüssel und dergleichen. Die Verbindung kann aus verschiedenen Gründen vollständig fehlschlagen, häufig aufgrund einer fehlenden Proxy-Konfiguration in Unternehmensumgebungen (es besteht keine direkte Verbindung zum Internet, der gesamte Internetverkehr wird über einen bestimmten Cache-Server geleitet und jeder Prozess muss Anmeldeinformationen bereitstellen, um die Firewall zu passieren). . Hier ist ein Artikel über die Gefahren der Lizenzüberprüfung über das Setup .
• Installshield wird verwendet, um eine Laufzeit für die Installscript- Sprache zu installieren . Dieses vorausgesetzte Setup war im Allgemeinen in der Datei setup.exe enthalten und war eine legendäre Quelle für Probleme . Es gab viele Versionen, verschiedene Inkompatibilitäten und eine Reihe von Laufzeitfehlern . Seit Version 12 (oder so ungefähr) ist diese Laufzeit zuverlässig installiert, und es wird entweder auf native Weise kompiliert oder Sandboxed (ich bin mir nicht sicher, welches - wahrscheinlich Sandboxed) auf zuverlässige Weise ausgeführt. Ältere Installshield-Setups können dieses Bereitstellungsproblem jedoch anzeigen. Es gibt eine ältere Support-Website von Installshield für Probleme wie diese: http://consumer.installshield.com/common.asp
• Einige Setups können ein fehlerhaftes Installationsverhalten oder zeitweise auftretende Fehler aufweisen, wenn sie auf Computern ausgeführt werden, die für andere Sprachen als Englisch eingerichtet sind, oder wenn Sie lokalisierte (übersetzte) Versionen von Setups auf englischen Computern ausführen . Dies kann ein reiner Laufzeitfehler sein oder der Fall, dass die lokalisierten Dialogfelder abgeschnittenen Text oder fehlerhafte Formatierungen oder fehlerhafte Übersetzungen oder viele andere Arten von Fehlern im Zusammenhang mit der Sprachlokalisierung enthalten- ein ganzes Fachgebiet für sich allein (Texte in Bilder übersetzen, Software selbst übersetzen, Marketingmaterial übersetzen, internationale Supportanfragen bearbeiten, Anpassung an die Spracheinstellungen des Betriebssystems usw.). Bei einigen Sprachen muss die gesamte Anwendung geändert werden, um den sprachlichen Besonderheiten Rechnung zu tragen. Typische Probleme sind Zeichenfolgenmakros und Codepage-Einstellungen. Letztere sind bei der Einführung von Unicode weniger problematisch. Sehen Sie sich einen Beispiel-Screenshot eines Übersetzungstools an .
• Fast alle Setups schlagen mehrere der integrierten Validierungstests fehl , die zum Testen der Qualität von MSI-Paketen verfügbar sind. In diesem Artikel finden Sie ein praktisches Beispiel für die Validierung.
• Manchmal schlagen Upgrades für ein MSI fehl, da bei größeren Upgrades nur drei Stellen der MSI-Versionsnummer überprüft werden.
• Die Installation von INI-Dateien ist eine integrierte Funktion von Windows Installer. Einträge können auf beliebige Weise hinzugefügt, entfernt, zusammengeführt oder bearbeitet werden. Es kommt jedoch häufig vor, dass INI-Dateien als Datei anstatt als segmentierte Werte installiert werden. Dies kann dazu führen, dass die INI-Datei während der Neuinstallation überschrieben wird, anstatt aktualisiert zu werden. Ein sehr verbreitetes MSI-Problem.
• Das obige Problem tritt auch bei .NET-Anwendungen und deren Config.xml-Dateien auf. In diesem Fall verfügt MSI NICHT über eine integrierte Methode zum detaillierten Aktualisieren des Inhalts. Sie müssen das Update entweder über eine benutzerdefinierte Aktion codieren oder die gesamte Datei bei der Installation ersetzen. Wix verfügt möglicherweise über neue Funktionen, die in der Windows Installer-Engine jedoch nicht integriert sind.

Es gibt eine Reihe subtilerer Fehler und einige größere, typische Probleme, die ich vergessen haben werde.

Lesen Sie den Windows Installer Best Practice- Artikel von MSDN .

Die Verwendung von MSIs erleichtert auch das Patchen (MSP-Dateien) und Upgrades. MSIs verwenden das Konzept eindeutiger Produkt- und Upgrade-Codes, die den gesamten Prozess vereinfachen.

Einige Bereitstellungssysteme (CA Unicenter Software Delivery ist ein Beispiel) können MSIs auch auf besondere Weise verstehen, sodass sie sich viel besser in das Bereitstellungssystem integrieren lassen. Beispielsweise können Sie eine MSI in die Softwarebibliothek des Bereitstellungssystems einspeisen. Diese erkennt automatisch die verschiedenen Funktionen des Produkts und ermöglicht automatisch differenziertere benutzerdefinierte Aktionen (lokale Installation, Überprüfung, Reparatur usw.) und Protokollierung.

Selbstheilung / Reparatur ist auch ein großes Plus für MSIs.

Schauen Sie sich auch Open Source Windows Installer XML an , "ein Toolset, das Windows-Installationspakete aus XML-Quellcode erstellt. Das Toolset unterstützt eine Befehlszeilenumgebung, die Entwickler in ihre Erstellungsprozesse integrieren können, um MSI- und MSM-Installationspakete zu erstellen." Dies wird von MS verwendet, um mehrere seiner wichtigsten Softwarepakete vorzubereiten.

Sie können Transformationen durchführen - theoretisch können Sie viele Anpassungen vornehmen. Wenn das Programm vom Hersteller ordnungsgemäß verpackt wurde, können Sie eine vollautomatische Bereitstellung ohne Interaktion mit dem Endbenutzer durchführen. Dies ist sehr hilfreich, wenn Sie Ihre Windows-Umgebung standardisieren möchten und mehr als eine Handvoll davon haben von Computern.

Um zu sehen, was Benutzer mit msis [oder unbeaufsichtigtem Deployment] machen, besuchen Sie zum Beispiel diese Site und ihre Foren.