O MSI não instala todos os arquivos quando remover a verificação é executada

Question

Eu tenho uma compilação MSI usando o Wix versão 3.

Todos os instaladores anteriores do produto que estamos implantando funcionaram bem com a configuração especificada (ou seja: se a versão anterior existir, remover e instalar a nova versão) - no entanto, o novo MSIS que construímos não instala todos os arquivos quando executar o caminho 'Remover primeiro'.

Se removermos manualmente a instalação existente e executarmos a nova versão, todos os arquivos serão instalados - e quando eu examino o arquivo MSI no ORCA, os arquivos e os recursos são mostrados e parecem estar bem.

Tentamos correr com um registro detalhado e extra ligado (/l*vx) No entanto, tudo o que podemos ver se os arquivos não estão sendo registrados e instalados.

Algum pensamento ou sugestão? Isso está nos levando pela parede.

Answer 1

Ok, bem conversando com outra pessoa onde me ajudou a encontrar uma solução para o problema.

Adicionamos a propriedade REINSTALLMODE e defina -o para amus. O que isto significa?

Por padrão, a propriedade está definida como omus O que significa: reinstalar se o arquivo estiver ausente ou mais antigo, reescreva o registro para colméias de máquinas e usuários, reinstale os atalhos. Mudando isso para amus Basicamente, diz: reinstale todos os arquivos.

Portanto, não 100% de certeza de qual era a causa - suspeito que possa ter havido mechas estranhas ou algo assim, mas definir para amus Não está em nenhum efeito adverso, então vamos continuar com isso.

Obrigado pelas sugestões.

(Além disso, mais detalhes sobre esta propriedade podem ser encontrados aqui: Msdn: reinstallmode Propriedade

Answer 2

Com base na sequência de ação personalizada padrão, o Windows Installer determina quais arquivos precisam ser instalados/substituídos antes de remover quaisquer versões existentes do software. O Windows Installer usa o valor da propriedade Reinstallmode para dizer como tomar decisões sobre quando substituir arquivos. Se o reinstallmode contiver um "O", ele instalará apenas arquivos onde a versão é diferente ou o arquivo ainda não existe; Os arquivos não versionados serão instalados apenas se a data modificada do arquivo for <= a data criada (ou seja, o arquivo não for modificado). Se o reinstallmode contiver um "A", ele sempre instalará o arquivo, independentemente de qualquer versão ou data de data anexada aos arquivos existentes.

O que está acontecendo em seu cenário é provavelmente o seguinte:

1. O Windows Installer determina quais arquivos instalar. Ele decide que alguns arquivos não precisam ser instalados (possivelmente porque já existem e são das mesmas versões mais ou mais recentes que as do MSI).
2. A versão anterior do software é removida, incluindo os arquivos que o Windows Installer determinado não precisava ser instalado.
3. O Windows Installer instala arquivos para a nova instalação, mas não instala arquivos que ele determinou que não precisa ser instalado.

O resultado final é que um monte de arquivos está ausente após a atualização do software. Configurar reinstallmode = Amus em vez de Omus provavelmente corrigirá seu problema, mas você deve saber como isso afeta o restante da sua instalação. Se houver arquivos que você não deseja ser substituído, precisará marcar esses componentes para "nunca substituir".

Answer 3

O que você faz <RemoveExistingProducts After=""> Passo parece? Pode ser que o RemofExisting esteja em execução após a instalação - e removendo todos os arquivos que eram iguais nas versões anteriores e atuais.

Eu tenho meu instalador definido para <RemoveExistingProducts After="InstallInitialize"> para garantir que seja feito antes de qualquer outra coisa. Não sei se está certo ou não, mas parece funcionar.

    <Upgrade Id="$(var.UpgradeCode)">
        <!--Upgrade code found at http://www.nichesoftware.co.nz/blog/200809/upgradable-msi-installations-with-wix -->
        <!-- Detect any newer version of this product-->
        <UpgradeVersion Minimum="$(var.version)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />

        <!-- Detect and remove any older version of this product-->
        <UpgradeVersion Maximum="$(var.version)" IncludeMaximum="yes" OnlyDetect="no" Language="1033" Property="OLDPRODUCTFOUND" />
    </Upgrade>
    <CustomAction Id="PreventDowngrading" Error="Newer version already installed"></CustomAction>
    <InstallExecuteSequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
        <RemoveExistingProducts After="InstallInitialize" />
    </InstallExecuteSequence>
    <InstallUISequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

Answer 4

Sei que este é um tópico mais antigo, mas encontrei um problema semelhante que não foi coberto pelas soluções. No meu caso, eu tinha uma DLL que era realmente uma versão número mais baixa do que seu antecessor. Esta DLL nunca apareceria em uma instalação de atualização. Corrida

msiexec /i myproduct.msi /l*vx install2.log

e verificação do log mostrou que o arquivo nunca foi instalado. Ele simplesmente não apareceu no log como um dos arquivos instalados. O MSI continha definitivamente o arquivo, a melhor evidência é que um reparo colocaria o arquivo. Além disso, explodir o MSI com várias ferramentas mostrou o arquivo presente. Uma instalação direta em uma máquina limpa sempre funcionava.

Isso não ajudou:

msiexec /i myproduct.msi REINSTALL=ALL REINSTALLMODE=amus /l*vx install3.log

Estou construindo o MSI com Wix e uso esse script há muitos anos. Mais recentemente, definimos o script para excluir completamente o diretório antigo em nossa versão 5.3. Isso funcionou para 5.2 -> 5.3 e 5.3 -> 5.4 Atualizações. Mas com a versão 5.5, as DLLs foram reconstruídas com novas versões das DLLs. Os projetos de DLL foram hospedados no Github. O script de compilação para essa DLL específico foi definido como uma versão de montagem de '10 .0.0. {Git Rev-List-Cabeça da contagem} '. O projeto havia sido movido, fazendo com que a contagem de cabeças vá de 444 para 30.

O wixscript inclui isso,

define ProductGuid = "{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}"

Por isso, atualizamos o produto GUID (não a atualização do produto GUID) sobre cada versão.

O remédio foi alterar levemente o script de construção desta DLL para definir a versão de montagem para ir para '10 .0.1. {Git Rev-List-Chefe de contagem} ', presumivelmente sendo tratado como uma versão numerada mais alta.

Por que isso funcionou, não consigo explicar.