Como implementar a atualização instalador WiX?

Question

No trabalho usamos WiX para a construção de pacotes de instalação. Queremos que a instalação do produto X resultaria na desinstalação da versão anterior desse produto na máquina.

Eu li em vários lugares na Internet sobre uma grande atualização, mas não conseguiu fazê-lo funcionar. Alguém pode por favor especifique as etapas exatas que eu preciso levar para adicionar funcionalidade versão desinstalação anterior para WiX?

Answer 1

Na as versões mais recentes (do 3.5.1315.0 beta), você pode usar o elemento MajorUpgrade em vez de usar o seu próprio.

Por exemplo, podemos usar esse código para fazer atualizações automáticas. Ela impede downgrades, dando uma mensagem de erro localizada, e também evita a atualização de uma versão idêntica já existente (ou seja, apenas versões menores são atualizados):

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

Answer 2

Finalmente eu encontrei uma solução - Estou postando aqui para outras pessoas que possam ter o mesmo problema (todos os 5 de você):

• Alterar a identificação do produto para *

• Sob produto adicione o seguinte:

  <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> 
  

• Sob InstallExecuteSequence add:

  <RemoveExistingProducts Before="InstallInitialize" /> 
  

A partir de agora, sempre que eu instalar o produto ele seja removido versões instaladas anteriores.

Nota: substituir atualizar Id com seu próprio GUID

Answer 3

A seguir é o tipo de sintaxe que eu uso para grandes atualizações:

<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>

A @ Brian Gillespie observou existem outros locais para agendar a RemoveExistingProducts dependendo optimizações desejadas. Observe o PUT-GUID-HERE devem ser idênticas.

Answer 4

O elemento de atualização dentro do elemento do produto, combinada com boa programação da ação irá realizar a desinstalação que você está depois. Certifique-se de listar os códigos de atualização de todos os produtos que você deseja remover.

<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>

Note que, se você for cuidadoso com seu constrói, você pode impedir as pessoas de instalar acidentalmente uma versão mais antiga de seu produto ao longo de um mais recente. Isso é o que o campo máxima é para. Quando construímos instaladores, montamos UpgradeVersion máxima para a versão que está sendo construído, mas IncludeMaximum = "no" para evitar este cenário.

Você tem escolhas sobre o agendamento de RemoveExistingProducts. Eu prefiro programar-lo depois InstallFinalize (em vez de depois InstallInitialize como outros têm recomendado):

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

Isso deixa a versão anterior do produto instalados até depois de os novos arquivos e chaves de registro são copiados. Isto deixa-me migrar dados da versão antiga para a nova (armazenamento por exemplo, você mudou de preferências do usuário a partir do registro para um arquivo XML, mas você quer ser educado e migrar suas configurações). Esta migração é feito em uma ação personalizada diferido pouco antes InstallFinalize.

Outra vantagem é a eficiência: se existem arquivos inalterados, o Windows Installer não incomoda copiá-los novamente quando você agendar após InstallFinalize. Se você agendar após InstallInitialize, a versão anterior é completamente removido primeiro, e depois a nova versão está instalado. Isso resulta em eliminação desnecessária e recopying de arquivos.

Para outras opções de agendamento, consulte o tópico RemoveExistingProducts ajuda no MSDN. Esta semana, o link é: http://msdn.microsoft.com/en- us / library / aa371197.aspx

Answer 5

Você pode ser melhor perguntar isso na WiX-users lista .

WiX é melhor usado com uma sólida compreensão do que o Windows Installer está fazendo. Você pode considerar a obtenção " The Definitive Guide to Windows Installer ".

A ação que remove um produto existente é a ação RemoveExistingProducts . Porque as consequências do que ele faz depende de onde ele está programado - ou seja, se uma falha faz com que o produto velho para ser reinstalado, e se os arquivos inalterados são copiados novamente -. Você tem que programá-lo-se

RemoveExistingProducts processa elementos <Upgrade> na instalação atual, combinando com o atributo @Id ao UpgradeCode (especificado no elemento <Product>) de todos os produtos instalados no sistema. O UpgradeCode define uma família de produtos relacionados. Quaisquer produtos que têm esta UpgradeCode, cujas versões cair no intervalo especificado, e onde o atributo UpgradeVersion/@OnlyDetect é no (ou é omitido), será removida.

A documentação para RemoveExistingProducts menciona definindo a propriedade UPGRADINGPRODUCTCODE. Isso significa que o processo de desinstalação para o produto que está sendo removida recebe essa propriedade, cujo valor é o Product/@Id para o produto que está sendo instalado.

Se a instalação original não incluiu uma UpgradeCode, você não será capaz de usar esse recurso.

Answer 6

I utilizaram esse local para me ajudar a compreender os conceitos básicos sobre WiX Upgrade:

http://wix.tramontana.co.hu/tutorial/upgrades -e-modularização

Depois eu criei uma amostra Installer, (instalado um arquivo de teste), em seguida, criou o instalador de atualização (instalado 2 arquivos de teste de amostra). Isso lhe dará uma compreensão básica de como funciona o mecanismo.

E como disse Mike no livro de Apress, "The Definitive Guide to Windows Installer", que irá ajudá-lo a entender, mas não é escrito usando WiX.

Outro site que foi muito útil foi esta:

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

Answer 7

Eu li o WiX documentação, baixado exemplos, mas eu ainda tinha muitos problemas com Atualizações. pequenas atualizações não executar desinstalação dos produtos anteriores, apesar da possibilidade de especificar aqueles desinstalação. Passei mais de um dia para as investigações e descobriu que WiX 3,5 intoduced uma nova etiqueta para upgrades. Aqui é o uso:

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

Mas o principal razão de problemas foi que a documentação diz para usar o " REINSTALL = ALL REINSTALLMODE = vomus " parâmetros para menores e pequenas atualizações, mas não dizem que esses parâmetros são PROIBIDO aos grandes atualizações - eles simplesmente parar de funcionar. Então você não deve usá-los com grandes atualizações.

Answer 8

Gostaria de sugerir ter um olhar para tutorial de Alex Shevchuk. Ele explica "grande atualização" através WiX com um bom hands-on exemplo em de MSI para o WiX, Parte 8 -. grande atualização

Answer 9

Uma coisa importante que eu perdi a partir dos tutoriais para um tempo (roubado http://www.tramontana.co .hu / Wix / lesson4.php ) que resultou nos erros "Outra versão deste produto já está instalado":

* Pequenas atualizações médios pequenas alterações em um ou alguns arquivos, onde a mudança não justificam mudar a versão do produto (major.minor.build). Você não tem que mudar o GUID do produto, tampouco. Note-se que você sempre tem que mudar o GUID do pacote quando você criar um novo arquivo .msi que é diferente dos anteriores em qualquer aspecto. O Installer mantém o controle de seus programas instalados e encontra-los quando o usuário deseja alterar ou remover a instalação usando esses GUIDs. Usando o mesmo GUID para diferentes pacotes vai confundir o programa de instalação.

pequenas atualizações mudanças indicar onde a versão do produto já vai mudar. Modificar o atributo Versão do Produto Tag. O produto permanecerá o mesmo, para que você não precisa mudar o GUID do produto, mas, é claro, obter um novo pacote GUID.

grandes atualizações denotam mudanças significativas como indo de uma versão completa para outro. Mudar tudo:. Atributo Version, produto e embalagem GUIDs

Answer 10

Eu estou usando a última versão do WiX (3.0) e não poderia começar o trabalho acima. Mas isso fez trabalho:

<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>

Note que PUT-GUID-aqui deve ser o mesmo que o GUID que você definiu na propriedade UpgradeCode do Produto.

Answer 11

A seguir trabalhou para mim.

<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>

Certifique-se de que o UpgradeCode do Produto está combinando a Id em Upgrade.

Answer 12

Isto é o que funcionou para mim, mesmo com grande BAIXO grau:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />