Domanda

Al lavoro utilizziamo WiX per la creazione di pacchetti di installazione. Vogliamo che l'installazione del prodotto X comporti la disinstallazione della versione precedente di quel prodotto su quella macchina.

Ho letto in diversi punti su Internet un aggiornamento importante ma non sono riuscito a farlo funzionare. Qualcuno può specificare i passaggi esatti che devo prendere per aggiungere la funzionalità di disinstallazione della versione precedente a WiX?

È stato utile?

Soluzione

Nelle versioni più recenti (dalla versione 3.5.1315.0 beta), è possibile utilizzare MajorUpgrade element invece di usare il tuo.

Ad esempio, utilizziamo questo codice per eseguire aggiornamenti automatici. Impedisce il downgrade, fornendo un messaggio di errore localizzato e impedisce anche l'aggiornamento di una versione identica già esistente (ovvero vengono aggiornate solo le versioni precedenti):

<MajorUpgrade
    AllowDowngrades="no" DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
    AllowSameVersionUpgrades="no"
    />

Altri suggerimenti

Finalmente ho trovato una soluzione - la sto pubblicando qui per altre persone che potrebbero avere lo stesso problema (tutti e 5):

  • Cambia l'ID prodotto in *
  • Sotto il prodotto aggiungi quanto segue:

    <Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
    <Upgrade Id="YOUR_GUID">  
       <UpgradeVersion
          Minimum="1.0.0.0" Maximum="99.0.0.0"
          Property="PREVIOUSVERSIONSINSTALLED"
          IncludeMinimum="yes" IncludeMaximum="no" />
    </Upgrade> 
    
  • In InstallExecuteSequence aggiungere:

    <RemoveExistingProducts Before="InstallInitialize" /> 
    

D'ora in poi ogni volta che installo il prodotto rimuoveva le versioni precedenti installate.

Nota: sostituisci l'ID upgrade con il tuo GUID

Di seguito è riportato il tipo di sintassi che utilizzo per i principali aggiornamenti:

<Product Id="*" UpgradeCode="PUT-GUID-HERE" Version="$(var.ProductVersion)">
 <Upgrade Id="PUT-GUID-HERE">
    <UpgradeVersion OnlyDetect="yes" Minimum="$(var.ProductVersion)" Property="NEWERVERSIONDETECTED" IncludeMinimum="no" />
    <UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" Property="OLDERVERSIONBEINGUPGRADED" IncludeMaximum="no" />
</Upgrade>

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

Come notato da @Brian Gillespie, ci sono altri posti dove pianificare i prodotti RemoveExisting in base alle ottimizzazioni desiderate. Nota che PUT-GUID-HERE deve essere identico.

L'elemento Upgrade all'interno dell'elemento Product, combinato con la corretta pianificazione dell'azione, eseguirà la disinstallazione che stai cercando. Assicurati di elencare i codici di aggiornamento di tutti i prodotti che desideri rimuovere.

<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="00000000-0000-0000-0000-000000000000">
  <UpgradeVersion Minimum="1.0.0.0" Maximum="1.0.5.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>

Nota che, se stai attento con le tue build, puoi impedire alle persone di installare accidentalmente una versione precedente del tuo prodotto su una più nuova. Ecco a cosa serve il campo Massimo. Quando costruiamo i programmi di installazione, impostiamo UpgradeVersion Maximum sulla versione che si sta costruendo, ma IncludeMaximum = & Quot; no & Quot; per prevenire questo scenario.

Sono disponibili opzioni relative alla pianificazione di RemoveExistingProducts. Preferisco programmarlo dopo InstallFinalize (piuttosto che dopo InstallInitialize come altri hanno raccomandato):

<InstallExecuteSequence>
  <RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>

Questo lascia installata la versione precedente del prodotto fino a quando non vengono copiati i nuovi file e le chiavi del registro. Questo mi consente di migrare i dati dalla vecchia versione alla nuova (ad esempio, hai cambiato l'archiviazione delle preferenze dell'utente dal registro in un file XML, ma vuoi essere educato e migrare le loro impostazioni). Questa migrazione viene eseguita in un'azione personalizzata posticipata poco prima di InstallFinalize.

Un altro vantaggio è l'efficienza: se ci sono file invariati, Windows Installer non si preoccupa di copiarli di nuovo quando si pianifica dopo InstallFinalize. Se si pianifica dopo InstallInitialize, la versione precedente viene completamente rimossa per prima, quindi viene installata la nuova versione. Ciò comporta la cancellazione e la ricopiatura inutili dei file.

Per altre opzioni di pianificazione, consultare l'argomento della guida di RemoveExistingProducts in MSDN. Questa settimana, il link è: http://msdn.microsoft.com/en- us / library / aa371197.aspx

Potrebbe essere meglio chiedere questo alla Mailing list degli utenti WiX .

WiX viene utilizzato al meglio con una solida conoscenza di ciò che Windows Installer sta facendo. Potresti considerare di ottenere & Quot; La guida definitiva a Windows Installer ".

L'azione che rimuove un prodotto esistente è l'azione RemoveExistingProducts . Poiché le conseguenze di ciò che fa dipendono da dove è pianificato, ovvero se un errore provoca la reinstallazione del vecchio prodotto e se i file invariati vengono copiati di nuovo, è necessario pianificarlo da soli.

RemoveExistingProducts elabora <Upgrade> elementi nell'installazione corrente, facendo corrispondere l'attributo @Id all'attributo UpgradeCode (specificato nell'elemento <Product>) di tutti i prodotti installati sul sistema. UpgradeVersion/@OnlyDetect definisce una famiglia di prodotti correlati. Tutti i prodotti che dispongono di questo UpgradeCode, le cui versioni rientrano nell'intervallo specificato e in cui l'attributo no è UPGRADINGPRODUCTCODE (o omesso), verranno rimossi.

La documentazione per Product/@Id menziona l'impostazione della proprietà <=>. Significa che il processo di disinstallazione per il prodotto che viene rimosso riceve quella proprietà, il cui valore è <=> per il prodotto che viene installato.

Se l'installazione originale non includeva un <=>, non sarà possibile utilizzare questa funzione.

Ho usato questo sito per aiutarmi a capire le basi dell'aggiornamento WiX:

http://wix.tramontana.co.hu/tutorial/upgrades -e-modularizzazione

Successivamente ho creato un programma di installazione di esempio (installato un file di prova), quindi ho creato il programma di installazione di aggiornamento (installato 2 file di prova di esempio). Questo ti darà una comprensione di base di come funziona il meccanismo.

E come ha detto Mike nel libro di Apress, " La guida definitiva a Windows Installer " ti aiuterà a capire, ma non è scritto usando WiX.

Un altro sito che è stato molto utile è stato questo:

http: // www .wixwiki.com / index.php? title = Main_Page

Ho letto la WiX , gli esempi scaricati, ma ho ancora avuto molti problemi con aggiornamenti. Gli aggiornamenti minori non eseguono la disinstallazione dei prodotti precedenti nonostante la possibilità di specificarli. Ho trascorso più di un giorno per le indagini e ho scoperto che WiX 3.5 ha introdotto un nuovo tag per gli aggiornamenti. Ecco l'uso:

<MajorUpgrade Schedule="afterInstallInitialize"
        DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." 
        AllowDowngrades="no" />

Ma il motivo principale dei problemi era che la documentazione dice di usare il " REINSTALL = ALL REINSTALLMODE = vomus " parametri per aggiornamenti minori e di piccole dimensioni, ma ciò non significa che tali parametri siano VIETATI per gli aggiornamenti importanti - semplicemente smettono di funzionare. Quindi non dovresti usarli con importanti aggiornamenti.

Suggerirei di dare un'occhiata al tutorial di Alex Shevchuk. Spiega & Quot; aggiornamento importante & Quot; tramite WiX con un buon esempio pratico in Da MSI a WiX, parte 8 - Aggiornamento principale .

Una cosa importante che mi mancava dai tutorial per un po '(rubata da http://www.tramontana.co .hu / wix / lezione4.php ) che ha portato al " Un'altra versione di questo prodotto è già installata " errori:

* Piccoli aggiornamenti significano piccole modifiche a uno o pochi file in cui la modifica non garantisce la modifica della versione del prodotto (major.minor.build). Non è necessario modificare nemmeno il GUID del prodotto. Si noti che è sempre necessario modificare il GUID del pacchetto quando si crea un nuovo file .msi diverso da quelli precedenti sotto qualsiasi aspetto. Il programma di installazione tiene traccia dei programmi installati e li trova quando l'utente desidera modificare o rimuovere l'installazione utilizzando questi GUID. L'uso dello stesso GUID per pacchetti diversi confonderà il programma di installazione.

Aggiornamenti minori indicano le modifiche in cui la versione del prodotto cambierà già. Modifica l'attributo Version del tag Product. Il prodotto rimarrà lo stesso, quindi non è necessario modificare il GUID del prodotto ma, ovviamente, ottenere un nuovo GUID del pacchetto.

Aggiornamenti importanti indicano cambiamenti significativi come passare da una versione completa all'altra. Cambia tutto: attributo versione, GUID prodotto e pacchetto.

Sto usando l'ultima versione di WiX (3.0) e non riesco a far funzionare quanto sopra. Ma questo ha funzionato:

<Product Id="*" UpgradeCode="PUT-GUID-HERE" ... >

<Upgrade Id="PUT-GUID-HERE">
  <UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND"
     Minimum="1.0.0.0"  IncludeMinimum="yes"
     Maximum="99.0.0.0" IncludeMaximum="no" />
</Upgrade>

Nota che PUT-GUID-HERE dovrebbe essere lo stesso del GUID che hai definito nella proprietà UpgradeCode del Prodotto.

Di seguito ha funzionato per me.

<Product Id="*" Name="XXXInstaller" Language="1033" Version="1.0.0.0" 
    Manufacturer="XXXX" UpgradeCode="YOUR_GUID_HERE">
<Package InstallerVersion="xxx" Compressed="yes"/>
<Upgrade Id="YOUR_GUID_HERE">
    <UpgradeVersion Property="REMOVINGTHEOLDVERSION" Minimum="1.0.0.0" 
        RemoveFeatures="ALL" />
</Upgrade>
<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

Assicurati che UpgradeCode nel Prodotto corrisponda all'ID in Upgrade.

Questo è ciò che ha funzionato per me, anche con il grado DOWN importante:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top