Compartilhar via

Melhores práticas do Windows Installer

  • Artigo

Esta seção enumera uma lista de dicas, vinculadas à documentação principal do SDK do Windows Installer, para ajudar os desenvolvedores de aplicativos, autores de instalação, profissionais de TI e desenvolvedores de infraestrutura a descobrir as práticas recomendadas para usar o Windows Installer:

Atualize a versão do Windows Installer.

  • Use o Windows Installer 5.0 no Windows Server 2008 R2 e no Windows 7. Esta é a versão do Windows Installer fornecida com o sistema operacional.
  • Use o Windows Installer 4.5 no Windows Server 2008, Windows Server 2003 com Service Pack 1 (SP1), Windows Vista com Service Pack 1 (SP1) ou Windows XP com Service Pack 2 (SP2). Para obter informações sobre como obter a versão mais recente do Windows Installer, consulte Windows Installer Redistributables.
  • Use o Windows Installer 3.1 no Windows 2000 com Service Pack 3 (SP3). O Windows Installer versão 3.1 tem recursos que facilitam a manutenção e a aplicação de patches de aplicativos.
  • Muitos recursos importantes foram introduzidos com a versão 3.0 e estão listados na seção Não suportado no Windows Installer versão 2.0. Os pacotes de instalação e as atualizações criados para o Windows Installer 2.0 podem ser instalados usando o Windows Installer 3.0 e posterior. Os pacotes de patch que contêm as novas tabelas usadas pelo Windows Installer 3.0 ainda podem ser aplicados usando versões anteriores do Windows Installer, mas sem a funcionalidade de aplicação de patch do Windows Installer 3.0. Também é possível criar patches que exijam explicitamente o Windows Installer 3.0 que não podem ser aplicados por versões anteriores do Windows Installer. Se um usuário não conseguir atualizar a versão do instalador, verifique se o aplicativo ou a atualização será compatível com uma atualização futura do Windows Installer.
  • Para obter uma lista dos recursos do Windows Installer não compatíveis com versões anteriores do instalador do Windows, consulte Novidades no Windows Installer.

Atende aos requisitos de certificação do logotipo do Windows.

  • Mesmo que você não pretenda enviar seu aplicativo para o programa de logotipo, seguir as diretrizes de certificação de logotipo pode ajudar a melhorar seu pacote do Windows Installer. Para obter uma visão geral dos requisitos de logotipo e links para programas de certificação de logotipo específicos, consulte Windows Installer e requisitos de logotipo.

Prepare o pacote para localização.

Atualize as ferramentas de desenvolvimento e a documentação do Windows Installer.

  • As Ferramentas Desenvolvimento do Windows Installer não são redistribuíveis e você só deve usar as versões dessas ferramentas disponíveis na Microsoft. Eles estão disponíveis nos Componentes do SDK do Windows para desenvolvedores do Windows Installer no SDK (Software Development Kit) do Microsoft Windows.
  • Vários fornecedores independentes de software oferecem ferramentas para criar ou modificar pacotes do Windows Installer. Essas ferramentas podem fornecer um ambiente de criação de pacotes que pode ser mais fácil de usar do que as ferramentas fornecidas no SDK do Windows Installer. Você pode saber mais sobre essas ferramentas nos recursos de informação discutidos em Outras fontes de informações do Windows Installer.
  • A capacidade de criar um pacote a partir de arquivos de texto pode ser mais intuitiva para alguns desenvolvedores. O conjunto de ferramentas do Windows Installer XML (WiX) disponível em Sourceforge.net compila pacotes de instalação do Windows a partir do código-fonte XML.
  • A documentação no Windows Installer SDK é atualizada com frequência.
  • Use a versão recente do Msizap.exe (versão 3.1.4000.2726 ou superior) que está disponível no Componentes do Windows SDK para desenvolvedores do Windows Installer para Windows Vista ou superior. Versões menores do Msizap.exe podem remover informações sobre todas as atualizações que foram aplicadas a outros aplicativos no computador do usuário. Se essas informações forem removidas, esses outros aplicativos podem precisar ser removidos e reinstalados para receber atualizações adicionais.
  • O editor de tabela de banco de dados Orca.exe é um editor de tabela de banco de dados para criar e editar pacotes do Windows Installer e módulos de mesclagem. Ele tem uma interface GUI básica, mas suporta edição avançada de bancos de dados do Windows Installer. Mesmo que você use outro aplicativo como sua principal ferramenta de desenvolvimento, pode achar conveniente usar o Orca.exe para solucionar problemas e testar um pacote.
  • Consulte Outras fontes de informações do Windows Installer para obter informações atuais sobre o Windows Installer disponíveis em blogs, chats técnicos, grupos de notícias, artigos técnicos e sites.

Se você decidir reempacotar um aplicativo de instalação herdado, siga as boas práticas de reempacotamento.

Muitos fornecedores de aplicativos fornecem pacotes nativos do Windows Installer para a instalação ou seus produtos. O software que converte um aplicativo de instalação herdado existente em um pacote do Windows Installer é chamado de ferramenta de reempacotamento. Reempacotar um aplicativo de instalação existente não é a melhor prática de desenvolvimento. Os aplicativos que foram projetados desde o início para aproveitar os recursos do Windows Installer podem ser mais fáceis para os usuários instalarem e manterem. Se você decidir usar um software de reempacotamento, as práticas a seguir podem ajudá-lo a produzir um pacote melhor do Windows Installer.

  • As ferramentas de reempacotamento convertem instalações herdadas em um pacote do Windows Installer tirando uma foto de um sistema de preparo antes e depois da instalação. Todas as alterações do registro, alterações de arquivo ou configuração do sistema que ocorrem durante o processo de captura são incluídas na instalação. Configure o hardware e o software do computador usado para reempacotar a instalação o mais próximo possível do sistema do usuário pretendido. Crie um pacote separado para cada configuração diferente de hardware. Reempacote usando um computador de preparo limpo. Remova todos os aplicativos desnecessários. Pare todos os processos desnecessários. Feche todos os serviços não essenciais do sistema.
  • Sempre faça uma cópia da instalação original antes de começar a trabalhar nela. Sempre trabalhe na cópia. Nunca pare um reempacotador antes que ele termine de compilar o pacote. Se o reempacotador danificar o pacote, você ainda terá o original.
  • Não reempacote as atualizações de software da Microsoft em um pacote do Windows Installer. A Microsoft lança atualizações de software, como service packs, em arquivos autoextraíveis que executam a instalação automaticamente. Essas atualizações usam instaladores diferentes do Windows Installer para substituir recursos protegidos do Windows e não podem ser convertidas em um pacote do Windows Installer. Para obter informações sobre como implantar service packs do Windows, consulte o guia de implantação do service pack no Microsoft TechNet.
  • Não use uma ferramenta de reempacotamento para converter um pacote do Windows Installer em um novo pacote. O Windows Installer adiciona informações de configuração ao sistema e também recursos do aplicativo. Quando uma ferramenta de reempacotamento compara o sistema antes e depois da instalação, o reempacotador interpreta incorretamente as informações de configuração como parte do aplicativo. Isso geralmente danifica o aplicativo reempacotado. Em vez disso, use transformações de personalização para modificar um pacote existente do Windows Installer ou criar um novo pacote. Você pode criar transformações de personalização usando a ferramenta Msitran.exe.
  • Não use uma ferramenta de reempacotamento para consolidar vários pacotes do Windows Installer em um único pacote. Em vez disso, você pode usar a ferramenta Msistuff.exe para configurar o executável de inicialização Setup.exe para instalar os pacotes um após o outro.
  • Crie seu pacote do Windows Installer de forma que ele possa ser facilmente personalizado pelo cliente. As variáveis globais usadas pelo Windows Installer durante uma instalação podem ser definidas usando propriedades públicas ou transformações de personalização. Forneça documentação sobre o uso dessas propriedades e valores padrão práticos para todos os valores personalizáveis. Para obter informações sobre como obter e definir propriedades, consulte Uso de propriedades. Para obter um exemplo de uma transformação de personalização, consulte Um exemplo de transformação de personalização..

Não tente substituir recursos protegidos.

Os pacotes do Windows Installer não devem tentar substituir recursos protegidos durante a instalação ou atualização. O Windows Installer não remove ou substitui esses recursos, porque o Windows impede a substituição de arquivos essenciais do sistema, pastas e chaves do registro. Proteger esses recursos evita falhas de aplicativos e sistemas operacionais.

  • Ao executar no Windows Server 2008 ou Windows Vista, o Windows Installer ignora a instalação de qualquer arquivo ou chave do registro protegido pela WRP (Proteção de Recursos do Windows), dessa forma o instalador insere um aviso no arquivo de log e continua com o restante da instalação sem erros. Para obter informações, consulte Uso do Windows Installer e Proteção de recursos do Windows.
  • WRP é o novo nome da Proteção de Arquivos do Windows (WFP). O WRP protege chaves e pastas do registro, bem como arquivos essenciais do sistema. No Windows Server 2003, Windows XP e Windows 2000, quando o Windows Installer encontrava um arquivo protegido pelo WFP, o instalador solicitava que o WFP instalasse o arquivo. Para obter informações, consulte Uso do Windows Installer e Proteção de recursos do Windows.

Não dependa de recursos não críticos.

Sua instalação ou atualização não deve depender da instalação de recursos não críticos pelos motivos a seguir.

  • As ações personalizadas podem falhar se dependerem de um componente pertencente a um recurso que o usuário anuncia em vez de instalar.
  • As ações personalizadas sequenciadas antes da ação InstallFinalize podem falhar se dependerem de um componente que contém um assembly que está sendo instalado. O Windows Installer não confirma assemblies no GAC (Cache de Assembly Global) até que a ação InstallFinalize seja concluída.

Use a API para recuperar informações de configuração do Windows Installer.

A instalação do aplicativo ou da atualização não deve depender do acesso direto às informações de configuração do Windows Installer salvas no computador. Em vez disso, use a interface de programação de aplicativos do Windows Installer para recuperar as informações de configuração. O local e o formato das informações de configuração são gerenciados pelo serviço Windows Installer e podem ser alterados.

Organize a instalação do seu aplicativo em torno de componentes.

O serviço Windows Installer instala ou remove coleções de recursos chamados de components. Como os componentes são comumente compartilhados, o autor de um pacote de instalação deve seguir regras ao especificar os componentes de um recurso ou aplicativo.

  • Siga as regras de componentes ao organizar aplicativos em componentes para garantir que novos componentes ou novas versões de componentes possam ser instalados e removidos sem danificar outros aplicativos. Você pode seguir o procedimento descrito em Definção de componentes do instalador.
  • O instalador rastreia cada componente pelo respectivo GUID de ID de componente especificado na tabela Componente. É essencial para a operação do mecanismo de contagem de referência do Windows Installer que o GUID da ID do componente esteja correto. Siga as diretrizes em Alteração do código do componente.
  • Se o seu pacote precisar quebrar as regras de componentes, esteja ciente das possíveis consequências e certifique-se de que sua instalação nunca instale esses componentes onde eles possam danificar componentes no sistema do usuário. Para obter informações, consulte O que acontece se as regras do componente forem quebradas?.
  • Esteja ciente de como o Windows Installer aplica as regras de controle de versão de arquivo ao substituir arquivos existentes. O Windows Installer primeiro determina se o arquivo de chave do componente já está instalado antes de tentar instalar qualquer um dos arquivos do componente. Se o instalador encontrar um arquivo com o mesmo nome do arquivo de chave do componente instalado no local de destino, ele comparará a versão, a data e a linguagem dos dois arquivos de chave e usará regras de controle de versão de arquivo para determinar se o componente fornecido pelo pacote deve ser instalado. Se o instalador determinar que precisa substituir a base do componente no arquivo de chave, ele usará as regras de controle de versão de arquivo em cada arquivo instalado para determinar se o arquivo deve ser substituído.

Reduza o tamanho de pacotes grandes do Windows Installer.

Pacotes muito grandes do Windows consomem recursos do sistema e podem ser difíceis de instalar pelos usuários. É uma boa prática reduzir o tamanho de pacotes muito grandes do Windows Installer pelos métodos a seguir.

  • Compacte os arquivos na instalação e armazene-os em um arquivo de gabinete (.cab). O instalador permite que o arquivo .cab seja armazenado como um arquivo externo e separado ou como um fluxo de dados no próprio pacote MSI. Para obter mais informações, confira Uso de gabinetes e fontes compactadas..
  • Remova o espaço de armazenamento desperdiçado no arquivo .msi usando uma das opções discutidas em Redução do tamanho de um arquivo .msi.
  • Se o pacote do Windows Installer contiver mais de 32767 arquivos, você deverá alterar o esquema do banco de dados. Para obter informações, consulte Criação de um pacote grande.

Se você usar ações personalizadas, siga as boas práticas de ação personalizada.

O Windows Installer possui muitas ações padrão internas para a instalação e manutenção de aplicativos. Os desenvolvedores devem tentar confiar nas ações padrão o máximo possível, em vez de criar suas próprias ações personalizadas. No entanto, há situações em que o desenvolvedor de um pacote de instalação acha necessário escrever uma ação personalizada.

Se você usar assemblies, siga as boas práticas recomendadas de assembly

Se seu pacote usa software de assemblies, follow the guidelines for Adding Assemblies to a Package, Updating Assemblies, and Installing and Removing Assemblies.

Não envie instalações simultâneas.

As Instalações Simultâneas, também chamadas de Instalações aninhadas, instalam outro pacote do Windows Installer durante uma instalação que estiver sendo executada no momento. A utilização de instalações simultâneas não é uma boa prática, uma vez que o seu serviço é difícil para os clientes. A aplicação de patches e a atualização podem não funcionar com instalações simultâneas. A alternativa recomendada para usar instalações simultâneas é usar um aplicativo de instalação e um manipulador de IU externo para instalar vários pacotes do Windows Installer sequencialmente.

Para obter mais informações sobre como usar um manipulador de IU externo, consulte Monitoramento de uma instalação usando MsiSetExternalUI. Para obter mais informações sobre como usar um manipulador externo baseado em registro, consulte Monitoramento de uma instalação usando MsiSetExternalUIRecord.

Às vezes, as instalações simultâneas são usadas em ambientes corporativos controlados para instalar aplicativos que não são destinados ao público. Siga estas diretrizes se decidir usar instalações simultâneas.

  • Não use instalações simultâneas para instalar ou atualizar um produto de envio.
  • As instalações simultâneas não devem compartilhar componentes.
  • Uma instalação administrativa não deve conter uma instalação simultânea.
  • ProgressBars integrados não devem ser usados com instalações simultâneas.
  • Os recursos que vão ser publicados não devem ser instalados por uma instalação simultânea.
  • Um pacote que executa uma instalação simultânea de uma aplicação deve também desinstalar a aplicação simultânea quando o produto principal é desinstalado. Existe uma instalação aninhada no contexto do produto principal em Adicionar/Remover programas no Painel de controle.

Mantenha os nomes e códigos de pacote consistentes.

O arquivo .msi pode receber qualquer nome que ajude os usuários a identificar o pacote, mas o nome não deve ser alterado sem alterar também o código do produto.

  • Dê ao arquivo .msi um nome de fácil utilização que habilite ao usuário habilitar o conteúdo do pacote do Windows Installer.
  • O código do produto é a principal identificação de um aplicativo e deve ser alterado sempre que houver uma atualização abrangente do aplicativo. Para obter informações, consulte ProductCode e Alteração do código do produto. Alterar o nome do arquivo .msi do aplicativo é considerado uma alteração abrangente e sempre requer uma alteração correspondente do código do produto para manter a consistência.
  • O código do pacote é o identificador primário usado pelo instalador para pesquisar e validar o pacote correto para uma determinada instalação. Dois arquivos de .msi não idênticos nunca devem ter o mesmo código de pacote. Se um pacote for alterado sem alterar o código do pacote, o instalador poderá não usar o pacote mais recente se ambos ainda estiverem acessíveis ao instalador. O código do pacote é armazenado na propriedade Resumo do número de revisão e no Fluxo de informações de resumo.
  • Note que as letras do código do produto e do código do pacote GUIDs devem estar todas em maiúsculas.

Não use as tabelas SelfReg e TypeLib.

  • Os autores do pacote de instalação são fortemente desaconselhados a usar o auto-registro e a tabela SelfReg. Em vez disso, eles devem registrar módulos criando uma ou mais tabelas no grupo de tabelas do registro. Muitos dos benefícios do Windows Installer são perdidos com o auto-registro porque as rotinas de autoregistro tendem a ocultar informações críticas de configuração. Para obter uma lista dos motivos para evitar o autoregistro, consulte a tabela SelfReg.
  • Os autores do pacote de instalação são fortemente desaconselhados a usar a tabela TypeLib. Em vez de usar a tabela TypeLib, registre as bibliotecas de tipos usando a tabela do registro. Se uma instalação usando a tabela TypeLib falhar e precisar ser revertida, a reversão poderá não restaurar o computador para o mesmo estado que existia antes da reversão.

Forneça a opção de instalar sem uma interface de usuário.

Os administradores geralmente preferem implantar aplicativos em uma corporação sem exigir interação do usuário. É uma boa prática habilitar que seu aplicativo forneça a opção de ser instalado com o nível de interface do usuário Nenhum.

  • Use propriedades públicas para obter informações de configuração. Os administradores podem fornecer essas informações na linha de comando.
  • Não exija que a instalação dependa das informações coletadas da interação do usuário com as caixas de diálogo. Essas informações não estão disponíveis durante uma instalação silenciosa.
  • Não reinicie automaticamente o computador do usuário durante uma instalação silenciosa.
  • Os administradores podem definir o nível da da interface do usuário durante a instalação usando a opção de linha de comando "/q". O nível da interface do usuário também pode ser definido programaticamente com uma chamada para MsiSetInternalUI.

Evite usar a política AlwaysInstallEleved.

Se a política AlwaysInstallElevated não estiver definida, os aplicativos não distribuídos pelo administrador serão instalados usando os privilégios do usuário e somente os aplicativos gerenciados obterão privilégios elevados. A definição dessa política direciona o Windows Installer a usar permissões do sistema ao instalar o aplicativo no sistema. Esse método pode abrir um computador para um risco de segurança, pois quando essa diretiva é definida, um usuário não administrador pode executar instalações com privilégios elevados e acessar locais seguros no computador. É uma boa prática utilizar outro método que não a política AlwaysInstallElevated quando estiver instalando um pacote com privilégios elevados para um não-administrador ou um patching de aplicações geridas por utilizador.

Habilite a política DisableMedia para limitar a instalação não autorizada.

A política DisableMedia pode impedir a instalação não autorizada de aplicativos. Quando esta política está habilitada, os utilizadores e administradores que executam uma instalação de manutenção de um produto são impedidos de utilizar a caixa de diálogo Procurar para procurar fontes de mídia, como CD-ROM, para as fontes de outros produtos instaláveis. A navegação por outros produtos é impedida, independentemente de a instalação ser feita com privilégios elevados. Ainda é possível que o usuário reinstale o produto a partir da mídia se o usuário tiver uma fonte de mídia rotulada corretamente.

Mantenha os arquivos de origem do pacote original seguros e disponíveis para os usuários.

Em alguns casos, a fonte original do pacote do Windows Installer pode ser necessária para instalar sob demanda, reparar ou atualizar um aplicativo. Se o instalador não conseguir localizar uma fonte disponível, o usuário será solicitado a fornecer mídia ou ir para um local de rede que contenha as fontes necessárias. É uma boa prática garantir que o instalador tenha as fontes necessárias sem precisar avisar o usuário.

  • Use assinaturas digitais e arquivos de gabinete externos para garantir que as fontes originais usadas pelo instalador sejam seguras. Uma imagem de origem não compactada armazenada em um local público não é segura.
  • Inclua uma lista completa de caminhos de origem de rede ou URL para o pacote de instalação do aplicativo na propriedade SOURCELIST.
  • Use um compartilhamento DFS (Sistema de Arquivos Distribuído) para o caminho de origem.
  • Use a API do Windows Installer para recuperar e modificar informações da lista de origem para aplicativos e patches do Windows Installer. Para obter informações, consulte Gerenciamento de fontes de instalação.
  • Use os métodos e as propriedades do objeto de instalação,, objeto do produto e objeto patch para recuperar e modificar informações da lista de fontes para aplicativos e patches do Windows Installer.
  • No entanto, para minimizar a possibilidade de que o patch exija acesso à fonte original, siga os pontos listados na seguinte seção: Impedir que um patch exija acesso à fonte de instalação original.
  • Armazene os arquivos de origem do pacote em um local que não seja a pasta temporária do sistema. Os arquivos de origem do Windows Installer armazenados na pasta temporária podem ficar indisponíveis para os usuários.

Habilite o log detalhado no computador do usuário ao solucionar problemas de implantação.

O log doWindows Installer inclui uma opção de log detalhada que pode ser habilitada no computador de um usuário. As informações em um log detalhado podem ser úteis ao tentar solucionar problemas de implantação de pacotes do Windows Installer.

  • Você pode habilitar o log detalhado no computador do usuário usando a propriedade Opções de linha de comando e os métodos MsiLogging, Logging policy, MsiEnableLog e EnableLog.
  • Um recurso muito útil para interpretar arquivos de log do Windows Installer é Wilogutl.exe. Essa ferramenta auxilia na análise de arquivos de log e exibe soluções sugeridas para erros encontrados em um arquivo de log.
  • A opção de log detalhado deve ser usada apenas para fins de solução de problemas e não deve ser deixada ativa, pois pode ter efeitos adversos no desempenho do sistema e no espaço em disco. Cada vez que você usa a ferramenta Adicionar/Remover programas no Painel de Controle, um novo arquivo é criado.

A desinstalação deixa o computador do usuário em um estado limpo.

A remoção do aplicativo é tão importante quanto a instalação. Quando um pacote do Windows Installer é desinstalado, ele não deve deixar partes inúteis de si mesmo no computador do usuário.

  • Se um arquivo que deveria ter sido removido do computador do usuário permanecer instalado após a execução de uma desinstalação, o instalador pode não estar removendo o componente que contém o arquivo por um ou mais dos motivos descritos em Remoção de arquivos encalhados.
  • Se um aplicativo precisar ser registrado, crie o pacote para remover as informações do registro quando o aplicativo for desinstalado. Para obter informações, consulte Adição ou remoção de chaves do registro na instalação ou remoção de componentes. Se um aplicativo não estiver registrado, ele não será listado no recurso Adicionar ou Remover programas no Painel de Controle e não poderá ser gerenciado usando o Windows Installer.
  • Para ocultar um aplicativo do recurso Adicionar ou Remover programas no Painel de Controle e ainda poder usar o Windows Installer para gerenciar o aplicativo, siga as diretrizes descritas em Adição e remoção de um aplicativo sem rastros no registro.
  • As ações personalizadas devem ser condicionadas a serem executadas ou não, conforme necessário, após a desinstalação. Diferentes ações personalizadas podem precisar ser executadas na instalação e desinstalação.
  • As informações de personalização específicas do usuário podem ser armazenadas em um arquivo de texto no computador. Isso tem a vantagem de que o arquivo pode ser removido quando o aplicativo é desinstalado, mesmo que o usuário dessa personalização não esteja conectado no momento.

Pacotes de teste para implantação de instalação por usuário e por computador.

É uma boa prática habilitar que os clientes decidam se desejam implantar um pacote para instalação no contexto de instalação por computador ou por usuário.

  • Considere se o aplicativo deve estar disponível apenas para usuários específicos ou para todos os usuários do computador durante o processo de desenvolvimento.
  • Teste se o pacote funciona corretamente para os contextos de instalação por usuário e por computador.
  • Torne o pacote facilmente personalizável e permita que os clientes decidam se desejam implantá-lo por usuário ou por computador.

Planeje e teste uma estratégia de manutenção antes de enviar o aplicativo.

Você deve decidir como pretende fazer a manutenção do aplicativo antes de implantá-lo pela primeira vez.

Reduza a dependência das atualizações das fontes originais.

Se os arquivos de origem originais forem necessários para atualizar seu aplicativo, isso poderá dificultar a manutenção do aplicativo. Os métodos a seguir podem ajudar a reduzir a dependência das atualizações das fontes originais.

Não distribua módulos de mesclagem inservíveis.

Os aplicativos não devem depender de módulos de mesclagem para a instalação do componente se o proprietário do módulo de mesclagem e o proprietário do aplicativo forem diferentes. Isso pode dificultar a manutenção do aplicativo porque ambos os proprietários precisam coordenar a atualização do aplicativo ou módulo. Sem conhecer todos os aplicativos que usaram o módulo de mesclagem, o proprietário do aplicativo não pode atualizar o módulo de mesclagem sem arriscar que a atualização seja incompatível com outro aplicativo. O proprietário do módulo de mesclagem não tem nenhum método direto para atualizar os pacotes do Windows Installer que já instalaram o módulo de mesclagem.

  • Considere fornecer os componentes necessários aos usuários como outra instalação do Windows Installer.

Evite aplicar patches em instalações administrativas.

Forneça em uma rede uma instalação administrativa do pacote original do Windows Installer do seu aplicativo para habilitar os membros de um grupo de trabalho a instalar o aplicativo. Os usuários dessa imagem administrativa devem aplicar atualizações à instância local do aplicativo localizada em seu computador. Isso mantém os usuários em sincronia com a imagem administrativa. A aplicação de atualizações à instalação administrativa não é recomendada pelos motivos a seguir.

  • O tamanho e a latência do download necessários para que os usuários obtenham uma atualização são maiores em comparação com o download de um patch. Todo o pacote atualizado do Windows Installer e os arquivos de origem devem ser baixados, armazenados em cache e reinstalados.
  • Os usuários não podem instalar sob demanda e reparar aplicativos de uma instalação administrativa atualizada até que rearmazenem em cache e reinstalem o aplicativo.
  • A aplicação de um patch a uma instalação administrativa remove a assinatura digital do pacote. O administrador deve renunciar ao pacote. Para obter mais informações sobre como usar assinaturas digitais, consulte Assinaturas digitais e Windows Installer.
  • Muitos patches binários têm como alvo a imagem RTM do aplicativo e exigem uma versão do arquivo anterior. A instância local de um aplicativo instalado a partir de uma instalação administrativa atualizada pode não funcionar com outras atualizações. Muitos aplicativos de patch binário podem falhar.
  • A aplicação de um patch a uma instalação administrativa atualiza os arquivos de origem e o arquivo .msi, mas não carimba a imagem de rede com informações sobre a atualização. Os usuários não podem determinar quais atualizações receberam da instalação administrativa. Isso torna impossível sequenciar as atualizações aplicadas no lado do usuário com aquelas já aplicadas no lado da imagem administrativa.
  • Os patches aplicados a uma instalação administrativa não são patches desinstaláveis. Isso pode impedir que o código do pacote armazenado em cache no computador do usuário se torne diferente do código do pacote na instalação administrativa. Se o código do pacote armazenado em cache no computador do usuário for diferente daquele na instalação administrativa, reinstale o aplicativo a partir da instalação administrativa e corrija o computador cliente.
  • Se você decidir aplicar pequenas atualizações corrigindo uma imagem administrativa, siga as diretrizes descritas no tópico: aplicação de pequenas atualizações na correção de uma imagem administrativa.

Registre as atualizações para serem executadas com privilégios elevados.

A partir do Windows Installer 3.0, é possível aplicar patches a um aplicativo que foi instalado em um contexto gerenciado por usuário, depois que o patch foi registrado como tendo privilégios elevados. Não é possível aplicar patches a aplicativos instalados em um contexto gerenciado por usuário utilizando versões do Windows Installer anteriores à versão 3.0.

Use a tabela MsiPatchSequence para sequenciar patches.

Inclua uma tabela MsiPatchSequence em seu pacote e adicione informações de sequenciamento de patches. A partir do Windows Installer versão 3.0, o instalador pode usar a Tabela MsiPatchSequence ao instalar vários patches para determinar a melhor sequência de aplicação de patch. Use as diretrizes descritas no white paper seqüenciamento de patch no Windows Installer versão 3.0 para definir famílias de patches.

  • Se possível, especifique todos os patches como pertencentes a uma única família de patches. Em muitos casos, uma única família de patches fornece flexibilidade suficiente para sequenciar patches. A complexidade da criação aumenta quando várias famílias de patches são usadas. Atribua um nome significativo à família de patches e atribua valores de sequência nessa família de patches que aumentam com o tempo. Siga o exemplo múltiplos patches para aplicar os patches na ordem em que foram emitidos.
  • Use a tabela PatchSequence na Patchwiz.dll para gerar as informações em MsiPatchSequence Table. A versão do PATCHWIZ.DLL lançada com o Windows Installer 3.0 pode gerar automaticamente informações de seqüenciamento de patch. Para obter mais informações sobre como adicionar um novo patch, consulte Geração de informações de sequência de patch. Para obter mais informações sobre cenários de sequenciamento de patch, consulte o white paper: Sequenciamento de patch no Windows Installer versão 3.0.

Teste o pacote de instalação completamente.

Teste a correta instalação, reparo e remoção do pacote do Windows Installer. Você pode dividir seu processo de teste nas partes a seguir.

  • Teste de instalação: teste a instalação com todas as combinações possíveis de recursos do aplicativo. Teste todos os tipos de instalação, incluindo a instalação administrativa, a instalação de reversão e a instalação sob demanda. Tente todos os métodos possíveis de instalação, inclusive clicar no arquivo .msi, opções de linha de comandoe instalar a partir do painel de controle. Teste se o pacote pode ser instalado pelos usuários em todos os contextos de privilégio possíveis. Tente instalar o pacote depois que ele tiver sido implantado por todos os métodos possíveis. Habilite o log do Windows installer para cada teste e resolva todos os erros encontrados no log do instalador e no log de eventos.
  • Teste de interface do usuário: teste o pacote quando instalado com todos os níveis possíveis de interface do usuário. Teste o pacote instalado sem interface do usuário e com todas as informações fornecidas por meio da interface do usuário. Verifique a acessibilidade da interface do usuário e que a interface do usuário funciona conforme o esperado para diferentes resoluções de tela e tamanhos de fonte.
  • Teste de manutenção e reparo: teste se o pacote pode lidar com patches e atualizações entregues por uma atualização pequena, atualização secundária e atualizações principais. Antes de implantar o pacote, escreva uma atualização de avaliação de cada tipo e tente aplicá-la ao pacote original.
  • Teste de desinstalação: verifique se, quando o pacote é removido, ele não deixa partes inúteis de si mesmo no computador do usuário e se apenas as informações pertencentes ao pacote foram removidas. Reinicialize o computador de teste após desinstalar o pacote e verifique a integridade das ferramentas comuns do sistema e outros aplicativos padrão. Teste se o pacote pode ser removido pelos usuários em todos os contextos de privilégio possíveis. Teste todos os métodos para remover o pacote, clique no arquivo .msi, tente as opções de linha de comando e tente remover o pacote do painel de controle. Habilite o log do Windows installer para cada teste e resolva todos os erros encontrados no log do instalador e no log de eventos.
  • Teste de funcionalidade do produto: certifique-se de que o aplicativo funcione conforme o esperado após a instalação, reparo ou remoção do pacote.

Corrija todos os erros de validação antes de implantar um pacote de instalação novo ou revisado.

Execute a validação do pacote em um pacote novo ou revisado do Windows Installer antes de tentar instalá-lo pela primeira vez. A validação verifica se há erros de criação no banco de dados do Windows Installer. A tentativa de instalar um pacote que não seja aprovado na validação pode danificar o sistema do usuário.

  • Você pode validar seu pacote usando Orca.exe ou Msival2.exe. Ambas as ferramentas são fornecidas com o SDK do Windows. Os fornecedores terceirizados também podem incorporar o sistema de validação ICE em seu ambiente de criação.
  • Você pode usar o conjunto padrão de Avaliadores de consistência interna - ICEs incluídos nos arquivos .cub fornecidos com o SDK ou personalizar a validação criando um ICE e adicionando-o ao arquivo .cub.
  • Você pode usar o Evalcom2.dll para implementar a automação de validação para pacotes de instalação e módulos de mesclagem.

Crie uma instalação segura.

Siga essas diretrizes ao desenvolver seu pacote para ajudar a manter um ambiente seguro durante a instalação.

Use PMSIHANDLE em vez de HANDLE

As variáveis do tipo PMSIHANDLE são definidas em msi.h. É recomendável que seu aplicativo use o tipo PMSIHANDLE porque o instalador fecha os objetos PMSIHANDLE à medida que saem do escopo, enquanto seu aplicativo deve fechar objetos MSIHANDLE chamando MsiCloseHandle. PMSIHandle fornece um operador de conversão para MSIHANDLE para compatibilidade de assinatura de API.

Por exemplo, se você usar um código como este:

MSIHANDLE hRec = MsiCreateRecord(3);

Mude-a para:

PMSIHANDLE hRec = MsiCreateRecord(3);