MSI-Referenzzählung: Zwei Produkte installieren dieselben MSIs

Das erste, was bei dieser Frage in den Sinn kommt, ist, ob die fraglichen Produkte so zersetzt sind, wie sie sein sollten.

Als allgemeine Regel glauben alle MSI-Dateien, dass sie alles besitzen, was sie installieren, und sie werden alles entfernen, das an eine Komponenten-GUID in der MSI bei der Deinstallation angehängt ist, wenn die Anzahl der Produkte die Komponente verwendet ) ist Null.

Für diese Regel gibt es einige Einschränkungen :

• Wenn die Komponente als permanent gekennzeichnet ist, wird sie niemals deinstalliert
• Wenn das Datei- / Registrierungselement überhaupt no component GUID hat, wird es installiert, nie von Windows Installer überwacht und auch nicht deinstalliert
• Schließlich ermöglicht die Referenzzählung für MSI , dass dieselbe Komponente für mehrere Produkte freigegeben wird und bei der Deinstallation auf der Festplatte verbleibt, wenn sie von mehreren anderen Installationspaketen registriert wird

Die Mechanismen zum Erstellen von gemeinsamen Komponenten zwischen MSI-Paketen sind im Allgemeinen:

1. Mit Zusammenführungsmodul können Sie gemeinsam genutzte Komponenten installieren, die als Referenz gezählt werden und die nach der Deinstallation eines verwandten Produkts auf dem Datenträger verbleiben, wenn andere Clients die GUID auf dem System verwenden. Ein Mergemodul wird zur Kompilierungszeit in andere MSI-Pakete integriert. Eine Form der binären frühen Bindung , wenn Sie möchten. Es kann in jedes Paket zusammengefügt werden.
2. Mit dem Aufkommen von Wix ( XML-basierte Installationsprogramm-Quelldateien) ist es möglich, das gleiche Segment von Dateien aus mehreren Setups über ein XML-Quellendatei anstelle eines Mergemoduls. Dies ist meiner Meinung nach deutlich besser, da Wix besser für die Quellcodeverwaltung geeignet ist ( siehe Wix Link zur Erklärung ). Es ist von entscheidender Bedeutung zu erkennen, dass eine " Wix-Quelleinschlussdatei " genau die gleiche Wirkung wie ein Zusammenführungsmodul hat - ihre Komponenten werden ordnungsgemäß für die Freigabe zwischen verschiedenen Installationspaketen gezählt , vorausgesetzt, die GUIDs in der Quelldatei sind fest codiert (ich empfehle, keine automatisch generierten Guids für diesen bestimmten Zweck zu verwenden). Es ist meine persönliche Meinung, dass Sie Drittanbieter-Mergemodule für generische Laufzeitdateien verwenden sollten, aber nur Wix für Ihre eigenen freigegebenen Dateien enthält. Merge-Module sind schwieriger zu verwalten als Wix enthält imho.

Aktualisierung und Dateiaustausch :

• Um Szenarien zu aktualisieren, werden die MSI-Dateiersetzungsregeln aktualisiert Aktualisieren Sie neuere Dateien, abhängig von der allgemeinen Einstellung in der speziellen Windows Installer-Eigenschaft REINSTALLMODUS .
• Im Allgemeinen überschreiben Dateien höherer Versionen niedrigere Versionsdateien. Nicht versionierte Dateien werden überschrieben, wenn sie nicht geändert wurden. Wenn sie geändert werden, sind die Erstellungsdatums- und Änderungsdatumsstempel unterschiedlich und die Datei wird in Ruhe gelassen.
• Beachten Sie, dass das Problem der Herunterstufung von Dateien durch das gesamte MSI-Design aktiv verhindert wird. Wenn Sie Dateien downgraden müssen (freigegeben oder nicht), gibt es etwas Deployment stinky zu Ihrem Design.

An dieser Stelle würde ich diese Antworten gründlich lesen:

• Windows Installer und die Erstellung von WiX - für eine kurze Wix Geschichte und Kontext
• Ändern Sie meine Komponenten-GUID in wix? - für die Zählung von Komponentenreferenzen
• Wix-Installation, Server, Client oder beides - für Client / Server-Pakete
• Wix, um mehrere Anwendungen zu installieren - zur Änderung von Anforderungen und Setup-Problemen
• WiX-Tricks und -Tipps - für Community-Wix-Tipps und Tricks
• Wie fügt man wxi-Dateien in wxs ein? - für eine einfache Idee, wie man mit Wix Include-Dateien umgehen kann

Vorausgesetzt, Sie verwenden Wix oder Sie sind bereit, Wix zu verwenden, würde ich meinen, dass die beste Lösung für überlappende Produkte darin besteht, Ihr Installationsprogramm in Wix-Segment-Quelldateien zu zerlegen benötigt in Ihren Haupt-Installern. Dies ermöglicht die Deinstallation eines Produkts, um Komponenten zu belassen, die von anderen Anwendungen verwendet werden.

Aus diesem Grund möchte ich nicht zu viele überlappende Abhängigkeiten in meinen Installern verursachen aus den in diesem Artikel aufgeführten Gründen (auch oben aufgeführt): Wix, um mehrere Anwendungen zu installieren .

Für Stabilität ist es von entscheidender Bedeutung, dass gemeinsame Komponenten stabil sind, bevor sie von zu vielen Setups verwendet werden als Bugfix als allgemeine Regel erfordert die Neukompilierung aller Setups, in denen die gemeinsame Komponente kompiliert oder zusammengeführt wird. Der einfache Weg, es zu sagen: bündeln Sie Dateien, die sich zusammen ändern .

Um dieser Notwendigkeit einer massiven Neukompilierung entgegenzuwirken, können Sie sich für ein eigenständiges unterstützendes Setup entscheiden, das aus einigen der gemeinsam genutzten Komponenten besteht. Einer oder einige solcher " geteilten Komponenten-Setups ", die wahrscheinlich Wix enthalten, enthalten diese Änderungen zusammen in einem ähnlichen langsamen Veröffentlichungsplan und trennen sich dann Setups für jedes Produkt sollten in der Lage sein, jedem Bereitstellungsbedarf Rechnung zu tragen und gleichzeitig ein Gleichgewicht zwischen Wartbarkeit und Flexibilität zu wahren.

Das Produkt-Setup sollte dann das sein, das oft neu kompiliert wird, und die gemeinsam genutzten Module sollten für eine minimale Neukompilierung ausgelegt sein. Dann warte auf wechselnde Anforderungen: -).

Für mich dreht sich alles um Zusammenhalt und Kopplung und die Schwierigkeit, Vertriebs-, Marketing- und technische Anforderungen in Einklang zu bringen.