2016-09-06 2 views
0

Ich habe eine MSI erstellt, die ein Konto und ein Passwort benötigt, um einen Windows Service zu installieren und zu starten, also habe ich meinem Element 'Product' ein paar Eigenschaften dafür hinzugefügt. Ich habe eine Anforderung, dass diese Eigenschaften nicht erneut für die Durchführung eines Upgrades bereitgestellt werden müssen, und da eine dieser Eigenschaften ein Kennwort ist, möchte ich den Wert für die Registrierung (oder anderswo) nicht beibehalten. Ich erreicht habe dies mitWix Bundle Upgrade ohne Nachspeise Password

<MajorUpgrade ... Schedule="afterInstallExecute" /> 

Jetzt habe ich eine exe-Bootstrap-Programm bin Authoring dieses MSI mit ihm ist Voraussetzung zu bündeln, in ähnlicher Weise die exe müssen Werte für die Eigenschaften empfangen und sie an das MSI passieren, also habe ich habe einige 'Variable' Elemente zu meinem Bundle hinzugefügt und sie an mein 'MsiPackage' Element mit den Child 'MsiProperty' Elementen übergeben. Dies funktioniert bei der Erstinstallation sehr gut, wenn die Werte geliefert werden. Wenn ich nun jedoch das Bundle aktualisieren möchte, ohne Werte für die Eigenschaften anzugeben, übergibt der Bootstrapper leere Werte an das MSI. Etwas entspricht dem ...

msiexec /i MyMsi.msi ACCOUNT= PASSWORD= 

Das bricht das Upgrade. Die neue Version des Windows-Dienstes versucht, mit einem leeren Wert für Konto und Kennwort zu beginnen.

Gibt es eine Möglichkeit, Variablenwerte als Eigenschaftswerte bedingt an MSI zu übergeben?

Was passiert, wenn beide Elementattribute 'Versteckt' und 'Bleib' gesetzt sind? Wird das Passwort wirklich versteckt?

Gibt es ein anderes Muster, von dem ich nichts weiß/nicht gedacht habe?

So etwas fühlt sich nicht an, als würde es eine benutzerdefinierte Aktion erfordern.

Antwort

1

Bei Upgrades können Sie die Standardaktion <InstallServices> deaktivieren.

In einem der Produkte, die ich mit denen ich arbeite habe folgendes:

<!-- http://stackoverflow.com/questions/15965539/how-to-only-stop-and-not-uninstall-windows-services-when-major-upgrade-in-wix don't change service config on upgrade --> 
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>    
<InstallServices>NOT WIX_UPGRADE_DETECTED OR V6INSTALLED</InstallServices> 

Weil ich will nicht den Starttypen der Dienste zurückgesetzt wird, hat der Benutzer beschlossen, sie manuell zu starten, anstatt automatisch von (Es ist eine Option in unserem Produkt, dies zu setzen).

Auf diese Weise soll es den Dienst bereits installiert lassen, wie ist, wenn anstatt zu versuchen, ein Upgrade mit leeren Parmeters für die Login-Benutzer erneut hinzufügen/pass


Eine Alternative ist, um einen gesalzenen Hash des Passworts zu machen und speichern Sie den Benutzer und gesalzen & Hash Passwort in die Registrierung. Bei Upgrades können Sie diese Werte lesen, das Passwort entschlüsseln und diese Werte verwenden.

+0

Ok. Das funktioniert für die Situation, die ich beschrieben habe. Aber ich habe auch eine sehr ähnliche Situation mit einem WebAppPool sowie einem Windows-Dienst. Wie kann ich das Gleiche erreichen? Und warum ist Wix so verdammt inkonsequent!?! –

+0

Und das Problem mit dem Speichern eines gesalzenen & Hash-Passworts in der Registrierung ist, dass das Kontopasswort zwischen Installation und Upgrade von Windows oder Active Directory geändert werden kann. –

+1

Ich fand schließlich, dass ich WIX_UPGRADE_DETECTED verwenden konnte, um das AppPool-Problem zu lösen. Deine Antwort hat das Problem in der Frage gelöst, also hol die Punkte. –

Verwandte Themen