Forçando uma atualização de um arquivo que é modificado durante a instalação inicial

Question

Eu estou trabalhando no recurso de atualização para o meu instalador baseado em WiX.

Como parte da instalação, estamos instalando um arquivo web.config e, em seguida, usando uma ação personalizada para atualizar as seqüências de conexão dentro do arquivo.

Mas isso causa um problema quando executar o nosso upgrade. Nós gostaríamos de ter os RemoveExistingProducts agendados para depois InstallFinalize uma vez que este é mais eficiente em termos de não remover e reinstalar os arquivos que não foram alterados. Mas isso deixa o arquivo web.config original no lugar no momento em que o Windows Installer está tentando determinar se ele deve atualizá-lo ou não. Desde a sua data da última modificação é mais recente do que a sua data de criação, o Windows Installer decide não atualizá-lo (ver regras versionamento que utiliza o Windows Installer). Mas precisamos que ele seja atualizado.

Uma solução óbvia é a de mudar a programação de RemoveExistingProducts para depois InstallValidate - mas isso é ineficiente, e também, eu não acho que isso nos daria a oportunidade de configurações migrar de arquivos existentes, devem precisamos fazer isso.

Quaisquer outras ideias?

Answer 1

Há muitas maneiras - nenhum é ideal

.

1: Você pode usar um arquivo companheiro para atualização vigor do arquivo em questão. Desde que o arquivo companheiro especificado sempre é atualizado, este pode ser o caminho a percorrer. Essencialmente, isso significa que você vincular o arquivo não-versionadas à lógica atualização de versão de seu arquivo companheiro (arquivos são atualizados em conjunto). Eu nunca usei isso em WIX, mas eu acho que é tão fácil quanto adicionar o atributo CompanionFile a um elemento do arquivo e aponte para o ID do arquivo que você deseja "versão follow". Dentro do arquivo MSI que será algo parecido com isto:

2: Você pode usar um ação personalizada para excluir o arquivo antes de custeio arquivo (ou ainda melhor, renomeá-lo para um formato de backup). O problema é que, se a instalação falhar o arquivo será em falta. Se você mudar o nome do arquivo em vez de excluir, você pode colocá-lo de volta no caso do programa de configuração falha através de uma ação personalizada reversão. Às vezes eu uso a tabela RemoveFile para remover arquivos em instalar, mas, dependendo do sequenciamento especificado no InstallExecuteSequence isso pode não trabalho (supressão deve acontecer antes msi faz custeio arquivo).

3: Depois, há a abordagem marreta : set REINSTALLMODE = amus para forçar sobrescrever todos os arquivos independentemente da versão. Eu não deveria sequer mencionar isso, pois é terrivelmente perigosa (você pode acabar arquivos do sistema substituir, ou em versões mais recentes do Windows provocar um erro de execução desagradável como arquivos são protegidos). Use-o apenas para dev testes, e não acho que isso é uma solução rápida. Ele causa mais problemas do que resolve.

Como uma variação, uma abordagem aceitável pode ser para definir o REINSTALLMODE para emus (substitua arquivos de versão mais velhas e os mesmos). Isso pode ajudar se você não quer para incrementar os números de versão, mas manter a reconstruir seus binários - como é o caso em um monte de .NET. Meu palpite é que isso fará com que toda uma nova gama de problemas embora - mais significativamente binários diferentes, mas a versão arquivos idênticos em estado selvagem se você usá-lo para lançamentos públicos - cheiro implantação se alguma vez houve um. Como um QA / DEV única abordá-lo poderia trabalhar embora. Mas, falando sério, por que se preocupar? Apenas auto-incremento a versão de compilação dos binários e que o problema é resolvido de forma confiável.

---

links :

• Como Explicitamente Retirar dll durante Majorupgrade Usando Wix Toolset

Answer 2

Somente aqueles duvidoso. Você pode remover o arquivo específico cedo com uma ação personalizada, mas não deixe de condicionar esse direito! Ou você pode especificar uma versão para o arquivo para atualizar regras irão tratá-lo como a substituição de um arquivo não-versionadas com um controle de versão um, mas depois manchas podem ficar nervosos sobre ter a versão errada deste arquivo.

Answer 3

Não use uma ação personalizada para atualizar seu arquivo de configuração é a outra idéia óbvia. Em vez de obter WIX para fazer a atualização através das extensões XML. Por exemplo.

<Component Id="web.config" Guid="f12ff575-ad5f-47bc-a5c9-40b1e3a7f9f5" >
    <File Source="$(var.SrcPath)\web.config.config" KeyPath="yes" />

    <util:XmlConfig Id="AppSqlInstanceName"
                    File="[#web.config]"
                    Action="create"
                    ElementPath="//configuration/connectionStrings/add[\[]@name='YourStringKey'[\]]"
                    Name="connectionString"
                    Node="value"
                    Value="metadata=res://*/YourModel.csdl|res://*/YourModel.ssdl|res://*/YourModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=[SQLSERVERANDINSTANCE];initial catalog=DatabaseName;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;"
                    On="install"/>
</Component>

Isso é usar um [SQLSERVERANDINSTANCE] variável que precisa ser configurado antes da mão.