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 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 melhor manutenção e aplicação de patches de aplicativos.
  • Muitos recursos importantes foram introduzidos com a versão 3.0 e estão listados na seção sem suporte 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 patch do Windows Installer 3.0. Também é possível criar patches que exigem explicitamente o Windows Installer 3.0 que não pode ser aplicado 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 suportados por versões anteriores do instalador do Windows, consulte O que há de novo no Windows Installer.

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

  • É uma boa prática preparar-se para localização futura ao criar o pacote de instalação original. Você pode seguir o procedimento de localização de pacote sugerido em Localizando um pacote do Windows Installer.

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

  • As ferramentas de 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 Microsoft Windows Software Development Kit (SDK).
  • 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ções 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 no Sourceforge.net cria pacotes de instalação do Windows a partir do código-fonte XML.
  • A documentação no SDK do Windows Installer lançada na MSDN Online Library é atualizada com mais frequência.
  • Use a versão recente do Msizap.exe (versão 3.1.4000.2726 ou superior) que está disponível nos componentes do SDK do Windows 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 talvez precisem 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 se você usar outro aplicativo como sua ferramenta de desenvolvimento principal, você pode achar que usar Orca.exe é conveniente ao solucionar problemas e testar um pacote.
  • Consulte Outras fontes de informações do Windows Installer para obter informações atuais do Windows Installer disponíveis em blogs, bate-papos 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 é conhecido como uma ferramenta de reempacotamento. Reempacotar um aplicativo de instalação existente não é a prática de desenvolvimento recomendada. 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 servirem. 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 ocorram durante o processo de captura são incluídas na instalação. Configure o hardware e o software do computador usados 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 de hardware diferente. 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. Trabalhe sempre na cópia. Nunca pare um reempacotador antes que ele termine de criar 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, como arquivos de extração automática 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, bem como recursos de 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 bootstrap Setup.exe para instalar os pacotes um após o outro.
  • Crie seu pacote do Windows Installer para 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 para 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 Usando 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 de sistema, pastas e chaves do Registro essenciais. A proteção desses recursos evita falhas de aplicativos e sistemas operacionais.

  • Ao ser executado no Windows Server 2008 ou no Windows Vista, o Windows Installer ignora a instalação de qualquer arquivo ou chave do Registro protegido pela Proteção de Recursos do Windows (WRP), o instalador insere um aviso no arquivo de log e continua com o restante da instalação sem erros. Para obter informações, consulte Usando o Windows Installer e a Proteção de Recursos do Windows.
  • WRP é o novo nome para a 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 encontrou um arquivo protegido por WFP, o instalador solicitaria que o WFP instalasse o arquivo. Para obter informações, consulte Usando o Windows Installer e a 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 seguintes motivos.

  • 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 para o 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 aplicativo do Windows Installer para recuperar 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.

  • As funções de instalação e configuração da API do Windows Installer são descritas na Referência da função do instalador.
  • As propriedades de configuração são descritas na Referência de propriedade.
  • Os métodos e propriedades de automação são descritos na Referência da Interface de Automação. O script de exemplo WiLstPrd.vbs se conecta a um objeto Installer e enumera produtos registrados e informações sobre produtos. Para obter informações, consulte Listar produtos, propriedades, recursos e componentes.

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 componentes. 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 Definindo componentes do instalador.
  • O instalador controla cada componente pelo respectivo GUID de ID de componente especificado na tabela Component. É essencial para a operação do mecanismo de contagem de referência do Windows Installer que o GUID de ID do componente esteja correto. Siga as diretrizes em Alterando o código do componente.
  • Se o pacote precisar quebrar as regras do componente, esteja ciente das possíveis consequências e certifique-se de que sua instalação nunca instale esses componentes onde eles possam danificar os componentes no sistema do usuário. Para obter informações, consulte O que acontece se as regras do componente forem quebradas?.
  • Lembre-se 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 o idioma dos dois arquivos-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 para os usuários. É uma boa prática reduzir o tamanho de pacotes muito grandes do Windows Installer pelos seguintes métodos.

  • Comprima os ficheiros na instalação e armazene-os num ficheiro de gabinete (.cab). O instalador permite que o arquivo .cab seja armazenado como um arquivo externo separado ou como um fluxo de dados no próprio pacote MSI. Para obter informações, consulte Usando gabinetes e fontes compactadas.
  • Remova o espaço de armazenamento desperdiçado no arquivo .msi usando uma das opções discutidas em Reduzindo o 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 Criando um pacote grande.

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

O Windows Installer tem 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 tanto quanto prático, 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.

  • Siga as diretrizes para Usar ações personalizadas.
  • Siga as diretrizes para proteger ações personalizadas. Ações personalizadas que usam informações confidenciais não devem gravar essas informações no log. Para obter informações, consulte Segurança de ação personalizada.
  • As Ações Personalizadas não devem tentar definir um ponto de entrada da Restauração do Sistema de dentro de uma ação personalizada. Para obter informações, consulte Definindo um ponto de restauração a partir de uma ação personalizada.
  • Retorne mensagens de erro de ações personalizadas e grave-as no log para facilitar a solução de problemas de ações personalizadas. Para obter informações, consulte Ações personalizadas de mensagem de erro e Retornando mensagens de erro de ações personalizadas.
  • Não altere o estado do sistema a partir de uma ação personalizada imediata. As ações personalizadas que alteram o sistema diretamente ou chamam outro serviço do sistema devem ser adiadas para o momento em que o script de instalação é executado. Cada ação personalizada de execução adiada que altera o estado do sistema deve ser precedida por uma ação personalizada de reversão para desfazer a alteração de estado do sistema em uma reversão de instalação. Para obter informações, consulte Alterando o estado do sistema usando uma ação personalizada.
  • As ações personalizadas que executam operações de instalação complexas devem ser um arquivo executável ou uma biblioteca de vínculo dinâmico. Limite o uso de ações personalizadas baseadas em scripts a operações de instalação simples.
  • Torne os detalhes do que sua ação personalizada faz com o sistema facilmente detectáveis pelos administradores do sistema. Coloque os detalhes das entradas do Registro e dos arquivos usados pela sua ação personalizada em uma tabela personalizada e faça com que a ação personalizada seja lida nessa tabela. Isso é demonstrado pelo exemplo em Usando uma ação personalizada para criar contas de usuário em um computador local. Para obter informações sobre como adicionar tabelas personalizadas a um banco de dados, consulte Trabalhando com consultas e exemplos de consultas de banco de dados usando SQL e script.
  • Uma ação personalizada não deve exibir uma caixa de diálogo. As ações personalizadas que exigem uma interface do usuário podem usar a função MsiProcessMessage. Consulte Enviando mensagens para o Windows Installer usando MsiProcessMessage.
  • As ações personalizadas não devem usar nenhuma das funções listadas na página: Funções não para uso em ações personalizadas.
  • Se a instalação se destinar a ser executada em um servidor de terminal, teste se todas as suas ações personalizadas são capazes de ser executadas em um servidor de terminal. Para obter mais informações, consulte TerminalServer propriedade.
  • Para que uma ação personalizada seja executada quando um patch específico é desinstalado, a ação personalizada deve estar presente no aplicativo original ou estar em um patch para o produto que é sempre aplicado. Para obter mais informações, consulte Ações personalizadas de desinstalação de patch.
  • As ações personalizadas não devem usar o nível da interface do usuário como condição para enviar mensagens de erro ao instalador, pois isso pode interferir no log e nas mensagens externas. Para obter informações, consulte Determinando o nível da interface do usuário a partir de uma ação personalizada.
  • Use instruções condicionais e sintaxe de instrução condicional para garantir que seu pacote execute corretamente ações personalizadas, não execute ações personalizadas ou execute ações personalizadas alternativas quando o pacote for desinstalado. Teste se o pacote funciona conforme o esperado ao desinstalar ações personalizadas. Para obter informações, consulte Condicionando ações a serem executadas durante a remoção
  • Se a instalação deve ser capaz de ser executada por usuários que não têm privilégios de administrador, teste para garantir que todas as ações personalizadas possam ser executadas com privilégios de não administrador. As ações personalizadas exigem privilégios elevados para modificar partes do sistema que não são específicas do usuário. O instalador pode executar ações personalizadas com privilégios elevados se um aplicativo gerenciado estiver sendo instalado ou se a diretiva do sistema tiver sido especificada para privilégios elevados. Quaisquer ações personalizadas que exijam privilégios elevados devem incluir as Opções de Execução no Script de Ação Personalizada msidbCustomActionTypeNoImpersonate no tipo de ação personalizada. Isso é demonstrado pelo exemplo em Usando uma ação personalizada para criar contas de usuário em um computador local.

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

Se o pacote usa assemblies de software, siga as diretrizes para Adicionar assemblies a um pacote, Atualizar assemblies e Instalar e remover 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 em execução no momento. O uso de instalações simultâneas não é uma boa prática porque elas são difíceis de serem atendidas pelos 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 interface do usuário externo para instalar vários pacotes do Windows Installer sequencialmente.

Para obter mais informações sobre como usar um manipulador de interface do usuário externo, consulte Monitorando uma instalação usando MsiSetExternalUI. Para obter mais informações sobre como usar um manipulador externo baseado em registro, consulte Monitorando uma instalação usando MsiSetExternalUIRecord.

Às vezes, instalações simultâneas são usadas em ambientes corporativos controlados para instalar aplicativos que não se destinam 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 remessa.
  • Instalações simultâneas não devem compartilhar componentes.
  • Uma instalação administrativa não deve conter uma instalação simultânea.
  • As ProgressBars integradas não devem ser usadas com instalações simultâneas.
  • Os recursos que devem ser anunciados não devem ser instalados por uma instalação simultânea.
  • Um pacote que executa uma instalação simultânea de um aplicativo também deve desinstalar o aplicativo simultâneo quando o produto pai é desinstalado. Existe uma instalação aninhada no contexto do produto pai em Adicionar ou 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 também alterar o código do produto.

  • Dê ao arquivo .msi um nome amigável que permita ao usuário identificar o conteúdo do pacote do Windows Installer.
  • O código do produto é a identificação principal de um aplicativo e deve ser alterado sempre que houver uma atualização abrangente do aplicativo. Para obter informações, consulte ProductCode e Alterando o código do produto. A alteração do nome do arquivo de .msi do aplicativo é considerada 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 procurar e validar o pacote correto para uma determinada instalação. Nenhum dos dois arquivos .msi não idênticos deve ter o mesmo código de pacote. Se um pacote for alterado sem alterar o código do pacote, o instalador não poderá usar o pacote mais recente se ambos ainda estiverem acessíveis ao instalador. O código do pacote é armazenado na propriedade Revision Number Summary do Summary Stream de Informações de Resumo.
  • Observe que as letras nos GUIDs de código do produto e de código do pacote devem ser todas 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 das tabelas no Grupo de Tabelas do Registro. Muitos dos benefícios do Windows Installer são perdidos com o registro automático porque as rotinas de auto-registro tendem a ocultar informações críticas de configuração. Para obter uma lista dos motivos para evitar o auto-registro, 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 bibliotecas de tipos usando a tabela do Registro . Se uma instalação usando a tabela TypeLib falhar e precisar ser revertida, a reversão pode não restaurar o computador para o mesmo estado que existia antes da reversão.

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

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

  • Use propriedades públicas para 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 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 interface do usuário ao instalar 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 AlwaysInstallElevated .

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 para usar permissões do sistema quando instala o aplicativo no sistema. Esse método pode abrir um computador para um risco de segurança, porque 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 usar outro método que não seja a política AlwaysInstallElevated ao instalar um pacote com privilégios elevados para aplicativos gerenciados por usuário que não sejam administradores ou aplicar patches.

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 essa política está habilitada, os usuários e administradores que executam uma instalação de manutenção de um produto são impedidos de usar 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 para o usuário reinstalar o produto 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 origem 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 de que precisa sem ter que avisar o usuário.

  • Use assinaturas digitais e arquivos de gabinete externos para garantir que as fontes origiais que estão sendo 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ídos) 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 Gerenciando fontes de instalação.
  • Use os métodos e as propriedades do Objeto do Instalador, do Objeto do Produto e do Objeto do Patch para recuperar e modificar as informações da lista de origem para aplicativos e patches do Windows Installer.
  • Siga os pontos listados em Impedindo que um patch exija acesso aos pontos de origem de instalação original para minimizar a possibilidade de que o patch exija acesso aos códigos-fonte originais.
  • 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 do Windows Installer inclui uma opção de log detalhado 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 Opções de Linha de Comando, a propriedade MsiLogging, a diretiva de Log, o método MsiEnableLog e EnableLog.
  • Um recurso muito útil para interpretar arquivos de log do Windows Installer é Wilogutl.exe. Essa ferramenta auxilia a 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 ativada, pois pode ter efeitos adversos no desempenho do sistema e no espaço em disco. Cada vez que você usa a ferramenta Adicionar ou 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 para trás 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 Removendo arquivos perdidos.
  • 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 Adicionando ou removendo chaves do Registro na instalação ou remoção de componentes. Se um aplicativo não estiver registrado, o aplicativo não está listado no recurso Adicionar ou remover programas no painel de controle e não pode 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 Adicionando e removendo um aplicativo e Não deixando rastreamento no Registro.
  • As ações personalizadas devem ser condicionadas para 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 se o usuário dessa personalização não estiver conectado no momento.

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

É uma boa prática permitir que os clientes decidam se implantam um pacote para instalação no contexto de instalação por máquina ou por usuário.

  • Considere se o aplicativo deve estar disponível apenas para usuários específicos ou 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 máquina.
  • Torne o pacote facilmente personalizável e permita que os clientes decidam se querem implantá-lo por usuário ou por máquina.

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 em relação às fontes originais.

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

  • Use um patch delta para atualizar as versões de linha de base do seu aplicativo, como a versão RTM e as versões do service pack. Siga as diretrizes para usar patches delta descritas no tópico: Reduzindo o tamanho do patch.
  • Siga as recomendações listadas no tópico: Impedindo que um patch exija acesso à fonte de instalação original.

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 se coordenar para atualizar o 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 correr o risco de que a atualização possa ser incompatível com outro aplicativo. O proprietário do módulo de mesclagem não tem nenhum método direto para atualizar 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 aplicativo para permitir que os membros de um grupo de trabalho instalem 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 sincronizados com a imagem administrativa. A aplicação de atualizações à instalação administrativa não é recomendada pelos seguintes motivos.

  • O tamanho e a latência do download necessários para que os usuários obtenham uma atualização são aumentados 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. Um 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 anterior do arquivo. 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 impossibilita a sequência de 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 se tornar 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: Aplicando pequenas atualizações aplicando patches em uma imagem administrativa.

Registre atualizações para serem executadas com privilégio elevado.

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

  • Use o método SourceListAddSource ou a função MsiSourceListAddSourceEx para registrar um pacote de patch como tendo privilégios elevados. Siga as diretrizes e exemplos fornecidos em Aplicando patches em Aplicativos gerenciados por usuário.
  • Ao executar o Windows Installer versão 4.0 no Windows Vista, você também pode usar o patch do UAC (Controle de Conta de Usuário ) para permitir que os autores de instalações do Windows Installer identifiquem patches assinados digitalmente que podem ser aplicados no futuro por usuários não administradores. Isso só está disponível com a instalação de pacotes no contexto de instalação por máquina (ALLUSERS=1).
  • Certifique-se de que o patch de privilégios mínimos não tenha sido desabilitado definindo a propriedade MSIDISABLELUAPATCHING ou a política DisableLUAPatching.

Use a tabela MsiPatchSequence para sequenciar patches.

Inclua uma tabela MsiPatchSequence em seu pacote e adicione informações de sequenciamento de patch. 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 Sequenciamento de patches no Windows Installer versão 3.0 para definir famílias de patches.

  • Se for prático, 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 de vários patches para aplicar patches na ordem em que foram emitidos.
  • Use a tabela PatchSequence no Patchwiz.dll para gerar as informações na tabela MsiPatchSequence. A versão do PATCHWIZ.DLL que foi lançada com o Windows Installer 3.0 pode gerar automaticamente informações de sequenciamento de patch. Para obter mais informações sobre como adicionar um novo patch, consulte Gerando informações de sequência de patch. Para obter mais informações sobre cenários de sequenciamento de patch, consulte o whitepaper: Sequenciamento de patch no Windows Installer versão 3.0.

Teste o pacote de instalação completamente.

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

  • 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 Instalação Administrativa, Instalação de Reversão e Instalação sob Demanda. Tente todos os métodos possíveis de instalação, incluindo clicar no arquivo .msi, opções de linha de comando e 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 de interface do usuário possíveis. Teste o pacote instalado sem interface de usuário e com todas as informações fornecidas através da interface do usuário. Certifique-se da acessibilidade da interface do usuário e que a interface do usuário funcione 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 fornecidos 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 para trás 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 de 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 de 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. Tentar instalar um pacote que não passa 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. 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 estas 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 objetos PMSIHANDLE à medida que eles saem do escopo, enquanto seu aplicativo deve fechar objetos MSIHANDLE chamando MsiCloseHandle. O 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);