Al lavoro utilizziamo WiX per creare pacchetti di installazione. Vogliamo che l'installazione del prodotto X comporti la disinstallazione della versione precedente di quel prodotto su quella macchina.
Ho letto su 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?
Risposte:
Nelle versioni più recenti (dalla versione 3.5.1315.0 beta), puoi utilizzare l' elemento MajorUpgrade invece di utilizzare 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 inferiori):
<MajorUpgrade
AllowDowngrades="no" DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
AllowSameVersionUpgrades="no"
/><MajorUpgrade>elemento " " deve essere posizionato dopo <Package> . In caso contrario, candleviene visualizzato il seguente errore: "errore CNDL0107: convalida dello schema non riuscita con il seguente errore alla riga 1, colonna 473: L'elemento 'Prodotto' nello spazio dei nomi ' schemas.microsoft.com/wix/2006/wi ' ha un elemento figlio non valido ' Aggiornamento principale "nello spazio dei nomi" schemas.microsoft.com/wix/2006/wi ". Elenco dei possibili elementi previsti:" Pacchetto ".".
AllowDowngradeso AllowSameVersionUpgrades. Di default non lo sono già.
Alla fine ho trovato una soluzione - la sto pubblicando qui per altre persone che potrebbero avere lo stesso problema (tutti e 5 voi):
Sotto prodotto aggiungere 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 aggiungi:
<RemoveExistingProducts Before="InstallInitialize" /> Da ora in poi ogni volta che installo il prodotto rimuovevano le versioni installate precedenti.
Nota: sostituire l'ID di aggiornamento con il proprio GUID
ProductVersionsupporta solo tre campi versione; pertanto il quarto campo non verrà affatto confrontato. Vedi la nota in VersionMin e VersionMax in msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
Di seguito è riportato il tipo di sintassi che utilizzo per gli aggiornamenti principali:
<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 PUT-GUID-HERE deve essere identico.
<InstallExecute After="RemoveExistingProducts" />. Il tuo esempio non ha questo: significa che il libro è sbagliato?
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 realizziamo i programmi di installazione, impostiamo UpgradeVersion Maximum sulla versione in fase di creazione, ma IncludeMaximum = "no" per impedire 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>Ciò lascia installata la versione precedente del prodotto fino a quando non vengono copiati i nuovi file e le chiavi di 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 appena 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
RemoveExistingProductsera programmato per dopo InstallFinalizee le dll non venivano aggiornate poiché assemblyVersion era invariato ma altri campi come AssemblyProduct lo erano. Non voglio essere in balia della routine di confronto dei file - voglio solo l'app precedente ANDATA
Potrebbe essere meglio chiedere questo sulla mailing list degli utenti WiX .
WiX viene utilizzato al meglio con una solida conoscenza di ciò che Windows Installer sta facendo. Potresti prendere in considerazione l'idea di ottenere " 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.
RemoveExistingProductselabora gli <Upgrade>elementi nell'installazione corrente, abbinando l' @Idattributo al UpgradeCode(specificato <Product>nell'elemento) di tutti i prodotti installati sul sistema. La UpgradeCodedefinisce una famiglia di prodotti correlati. Tutti i prodotti che dispongono di questo UpgradeCode, le cui versioni rientrano nell'intervallo specificato e in cui l' UpgradeVersion/@OnlyDetectattributo è no(o omesso), verranno rimossi.
La documentazione per le RemoveExistingProductsmenzioni sull'impostazione della UPGRADINGPRODUCTCODEproprietà. Significa che il processo di disinstallazione per il prodotto che viene rimosso riceve quella proprietà, il cui valore è il Product/@Idper il prodotto che viene installato.
Se l'installazione originale non include un UpgradeCode, 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-and-modularization
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:
Ho letto la documentazione WiX , scaricato esempi, ma ho ancora avuto molti problemi con gli 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 è che la documentazione afferma di utilizzare i parametri " REINSTALL = ALL REINSTALLMODE = vomus " per gli aggiornamenti minori e piccoli, ma non dice che quei parametri sono VIETATI per gli aggiornamenti principali - semplicemente smettono di funzionare. Quindi non dovresti usarli con importanti aggiornamenti.
Suggerirei di dare un'occhiata al tutorial di Alex Shevchuk. Spiega "aggiornamento importante" tramite WiX con un buon esempio pratico da Da MSI a WiX, Parte 8 - Aggiornamento principale .
Una cosa importante che mi mancava dai tutorial per un po '(rubato da http://www.tramontana.co.hu/wix/lesson4.php ) che ha provocato gli errori "Un'altra versione di questo prodotto è già installata":
* 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 con estensione 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.
Piccoli aggiornamenti indicano cambiamenti 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.
Gli 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>Si noti che PUT-GUID-HERE dovrebbe essere uguale al GUID 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 i principali voti DOWN :
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade AllowDowngrades="yes" />