Como implementar a atualização do instalador do WiX?

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

Eu li em vários lugares na Internet sobre uma grande atualização, mas não consegui fazê-la funcionar. Alguém pode especificar as etapas exatas que preciso executar para adicionar o recurso de desinstalação da versão anterior ao WiX?

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

Por exemplo, usamos esse código para fazer atualizações automáticas. Impede downgrades, fornecendo uma mensagem de erro localizada, e também impede a atualização de uma versão idêntica já existente (ou seja, apenas as versões inferiores são atualizadas):

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

Finalmente, encontrei uma solução - estou postando aqui para outras pessoas que podem ter o mesmo problema (todos os 5):

• Altere o ID do produto para *

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

• Em InstallExecuteSequence, adicione:

  <RemoveExistingProducts Before="InstallInitialize" /> 

A partir de agora, sempre que instalo o produto, ele removeu as versões instaladas anteriores.

Nota: substitua o ID da atualização pelo seu próprio GUID

A seguir, é apresentado 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>

Como @Brian Gillespie observou, há outros locais para agendar os RemoveExistingProducts, dependendo das otimizações desejadas. Observe que PUT-GUID-HERE deve ser idêntico.

O elemento Upgrade dentro do elemento Product, combinado com o planejamento adequado da ação, executará a desinstalação que você procura. 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>

Observe que, se você for cuidadoso com suas compilações, poderá impedir que as pessoas instalem acidentalmente uma versão mais antiga do seu produto sobre uma mais nova. É para isso que serve o campo Máximo. Quando criamos instaladores, configuramos UpgradeVersion Maximum para a versão que está sendo criada, mas IncludeMaximum = "no" para evitar esse cenário.

Você tem opções sobre o agendamento de RemoveExistingProducts. Prefiro agendá-lo após o InstallFinalize (em vez de depois do InstallInitialize, como outros recomendaram):

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

Isso deixa a versão anterior do produto instalada até que os novos arquivos e chaves do registro sejam copiados. Isso permite migrar dados da versão antiga para a nova (por exemplo, você alterou o armazenamento das preferências do usuário do registro para um arquivo XML, mas deseja ser educado e migrar as configurações). Essa migração é feita em uma ação personalizada adiada imediatamente antes do InstallFinalize.

Outro benefício é a eficiência: se houver arquivos inalterados, o Windows Installer não se preocupará em copiá-los novamente quando você agendar após o InstallFinalize. Se você agendar após o InstallInitialize, a versão anterior será completamente removida primeiro e, em seguida, a nova versão será instalada. Isso resulta em exclusão e nova cópia desnecessárias de arquivos.

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

Você pode perguntar melhor isso na lista de discussão dos usuários do WiX .

O WiX é melhor usado com um entendimento firme do que o Windows Installer está fazendo. Você pode considerar obter " O Guia Definitivo do Windows Installer ".

A ação que remove um produto existente é a ação RemoveExistingProducts . Como as consequências do que ele faz depende de onde está agendado - a saber, se uma falha faz com que o produto antigo seja reinstalado e se os arquivos inalterados são copiados novamente - você precisa agendá-lo.

RemoveExistingProductsprocessa <Upgrade>elementos na instalação atual, correspondendo o @Idatributo ao UpgradeCode(especificado no <Product>elemento) de todos os produtos instalados no sistema. O UpgradeCodedefine uma família de produtos relacionados. Quaisquer produtos que tenham esse UpgradeCode, cujas versões se enquadram no intervalo especificado e onde o UpgradeVersion/@OnlyDetectatributo esteja no(ou seja omitido), serão removidos.

A documentação para RemoveExistingProductsmenções à configuração da UPGRADINGPRODUCTCODEpropriedade. Isso significa que o processo de desinstalação do produto que está sendo removido recebe essa propriedade, cujo valor é o Product/@Iddo produto que está sendo instalado.

Se a sua instalação original não incluiu um UpgradeCode, você não poderá usar esse recurso.

Usei este site para me ajudar a entender o básico sobre o WiX Upgrade:

http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization

Depois, criei um instalador de amostra (instalei um arquivo de teste) e depois criei o instalador de atualização (instalei 2 arquivos de teste de amostra). Isso lhe dará uma compreensão básica de como o mecanismo funciona.

E, como Mike disse no livro da Apress, "O Guia Definitivo do Windows Installer", ele ajudará você a entender, mas não foi escrito usando o WiX.

Outro site que foi bastante útil foi este:

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

Eu li a documentação do WiX , baixei exemplos, mas ainda tinha muitos problemas com atualizações. Atualizações menores não executam a desinstalação dos produtos anteriores, apesar da possibilidade de especificar essas desinstalações. Passei mais de um dia em investigações e descobri que o WiX 3.5 introduziu uma nova tag para atualizações. Aqui está o uso:

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

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

Eu sugeriria dar uma olhada no tutorial de Alex Shevchuk. Ele explica a "grande atualização" através do WiX com um bom exemplo prático de From MSI to WiX, Part 8 - Major Upgrade .

Uma coisa importante que perdi dos tutoriais por um tempo (roubada de http://www.tramontana.co.hu/wix/lesson4.php ) que resultou nos erros "Outra versão deste produto já está instalada":

* Pequenas atualizações significam pequenas alterações em um ou alguns arquivos nos quais a alteração não garante a alteração da versão do produto (major.minor.build). Você também não precisa alterar o GUID do produto. Observe que você sempre deve alterar o GUID do pacote ao criar um novo arquivo .msi diferente dos anteriores em qualquer aspecto. O instalador controla os programas instalados e os encontra quando o usuário deseja alterar ou remover a instalação usando esses GUIDs. Usar o mesmo GUID para pacotes diferentes confundirá o instalador.

Pequenas atualizações indicam mudanças nas quais a versão do produto já será alterada. Modifique o atributo Version da tag Product. O produto permanecerá o mesmo; portanto, você não precisa alterar o GUID do produto, mas, é claro, obter um novo GUID do pacote.

Grandes atualizações indicam mudanças significativas, como passar de uma versão completa para outra. Alterar tudo: atributo de versão, GUIDs de produtos e pacotes.

Estou usando a versão mais recente do WiX (3.0) e não consegui fazer o trabalho acima. Mas isso funcionou:

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

Observe que PUT-GUID-HERE deve ser igual ao GUID que você definiu na propriedade UpgradeCode do Produto.

Abaixo funcionou 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 no produto corresponda ao ID na atualização.

Isto é o que funcionou para mim, mesmo com as principais notas DOWN :

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