2012-10-22 16 views
9

Per darti un background - Ho 4 MSI che provengono dal nostro fornitore e questo deve andare ai server della nostra azienda (stiamo esaminando circa 3500 server). A partire da ora, le mie controparti stanno gestendo questo utilizzando vbs, script ps1. Ma il problema con lo script è che ogni volta che arriva un aggiornamento, dobbiamo preoccuparci di disinstallare il pacchetto esistente prima di eseguire il nuovo e un sacco di hardcoding.Come utilizzare CustomAction nel pacchetto WIX?

Desidero automatizzare l'intero processo (con molto meno hardcoding) impostando uno script WIX per raggruppare tutti i 4 MSI. Ho letto del bundle WIX e l'ho usato per creare un singolo MSI. Ma ora ci sono molte variabili da passare ai 4 MSI, quindi ho pensato di utilizzare le azioni personalizzate per impostare queste variabili in base all'ambiente/alla macchina su cui è in esecuzione MSI. Ma non posso fare azioni personalizzate per lavorare? Mi sto perdendo qualcosa?

Un po 'di google e ho visto qualcosa come non ci sono CustomActions in bundle? qualcuno può confermare?

Anche se non ci sono CA, quali sono le mie opzioni? come posso manipolare le variabili da passare ai 4 MSI? La maggior parte di essi deve essere impostata in base alla macchina su cui viene eseguita (come percorso di installazione, ID utente, ID pool di app ecc.).

risposta

4

come la vedo io, sono disponibili tre opzioni:

  1. a seconda di cosa informazioni necessarie, è possibile utilizzare il WixUtilExtension per eseguire operazioni semplici, come la lettura di chiavi di registro e l'esecuzione di ricerche di file, che è possibile quindi passare i risultati ai pacchetti di installazione come proprietà.

  2. Implementare azioni personalizzate nei singoli pacchetti di installazione (non nel pacchetto).

  3. Scrivere la propria applicazione bootstrapper personalizzata per determinare tutte le proprietà che è necessario impostare e quindi passarle ai pacchetti di installazione. Questo è più complessa di quanto la # 1 e # 2, ma se il vostro interesse i seguenti link dovrebbe iniziare: introducing managed bootstrapper applications e write a wpf wix installer

+0

Ha senso! Ho provato tutto il possibile per far funzionare la CA nel bundle e non viene chiamata. Da quello che ho capito, anche se il pacchetto WIX genera un file MSI, non è in realtà un MSI (non puoi eseguirlo con msiexec o aprirlo con ORCA). È solo un exe o un programma che combina tutti gli MSI insieme e non ha nessuna delle proprietà di un MSI. P.S: Penso solo a renderlo confuso MS lo ha chiamato come MSI :) – Isaiah4110

+0

@ user1766402, non mi ero nemmeno reso conto che era possibile emettere il bundle come msi finché non ho letto la tua domanda. È possibile fare clic con il tasto destro del mouse sul progetto in Visual Studio e selezionare Proprietà, quindi modificare l'output in .exe. Questo dovrebbe essere comunque l'impostazione predefinita per i progetti bundle/bootstrapper. – BryanJ

+3

Un bundle WiX non è un MSI, è un eseguibile. Rinominare l'exe in .msi non cambierà quello. :) –

9

C'è una quarta opzione, un utile trucco leggero, identificato da Vijay Kotecha (vedi http://vijayskotecha.blogspot.com/2013/07/wix-bootstrapper-custom-action.html), ...

In sostanza, creare un <ExePackage> attorno a un file batch .bat o .cmd pass-through. Il file batch/comando contiene la singola riga '%*' che esegue nuovamente tutti gli argomenti della riga di comando come un comando di prima classe.

Così:

<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd" 
    InstallCommand="my_custom_action.exe my_custom_parameters" /> 
<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd" 
    InstallCommand="my_next_action.exe my_next_parameters" /> 

Dove WixCustomAction.cmd è un file che contiene solo '%*'.

Questi <ExePackages> possono essere inseriti nello <Bundle><Chain> in successione se necessario utilizzando diversi InstallCommand se necessario.

Problemi correlati