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?
Antworten:
Nur ein paar Vorteile:
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 .
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?
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:
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.
Im Klartext sind die wirklich wichtigen Vorteile von MSI (in keiner bestimmten Reihenfolge):
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.
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.
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.
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.
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.
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.
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.
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 .
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.
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 .
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.
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.
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.
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.
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).
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).
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.
(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:
Spezielle Themen zur Vorgehensweise:
Konzeptionelle Themen / Best Practice:
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.
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):
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.