Partilhar via

Práticas recomendadas do Windows Installer

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 uma melhor manutenção de aplicativos e aplicação de patches.
  • 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 atualizações que foram 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 patches 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, certifique-se de que seu aplicativo ou 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 Novidades no Windows Installer.

Cumpra os requisitos de certificação do logótipo 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 específicos de certificação de logotipo, 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.

  • Os de 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 no Windows SDK Components for Windows Installer Developers 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 construir 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 Windows Installer SDK é atualizada com mais frequência.
  • Use a versão recente do Msizap.exe (versão 3.1.4000.2726 ou superior) disponível no Windows SDK Components for Windows Installer Developers for 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 principal ferramenta de desenvolvimento, 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 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 configuraçã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 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 prestarem serviços. 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 antigas num pacote do Windows Installer, capturando o estado de um sistema de preparação antes e depois da instalação. Quaisquer alterações no registo, alterações de ficheiros ou definições do sistema que ocorram 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 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.
  • Faça sempre 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 construir o pacote. Se o reempacotador danificar a embalagem, 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 automaticamente a instalação. 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 em 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 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, utilize personalizações como transformações 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.
  • Faça seu pacote do Windows Installer para que ele possa ser facilmente personalizado pelo cliente. As variáveis globais utilizadas pelo Windows Installer durante uma instalação podem ser configuradas por meio de propriedades públicas ou de 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 essenciais do sistema, pastas e chaves do Registro. A proteção desses recursos evita falhas de aplicativos e sistemas operacionais.

  • Quando executado no Windows Server 2008 ou Windows Vista, o Windows Installer ignora a instalação de qualquer arquivo ou chave do Registro protegido por WRP (Windows Resource Protection), o instalador insere um aviso no arquivo de log e continua com o restante da instalação sem erro. Para obter informações, consulte Usando o Windows Installer e o Windows Resource Protection.
  • WRP é o novo nome para a Proteção de Arquivos do Windows (WFP). WRP protege chaves de registro e pastas, bem como arquivos de sistema essenciais. 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 Usando o Windows Installer e o Windows Resource Protection.

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 contenha um assembly que está sendo instalado. O Windows Installer não regista as assemblies na Global Assembly Cache (GAC) 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 seu aplicativo ou atualização não deve depender do acesso direto às informações de configuração do Windows Installer salvas no seu computador. Em vez disso, use a interface de programação de aplicativos 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 de Funções do Instalador .
  • Os Propriedades de Configuração de são descritos 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 do produto. Para obter informações, consulte Lista de produtos, propriedades, funcionalidades e componentes.

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

O serviço Windows Installer instala ou remove coleções de recursos referidos como 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.

  • Respeite as regras de componentes quando organizar aplicações em componentes para garantir que novos componentes, ou novas versões de componentes, possam ser instalados e removidos sem danificar outras aplicações. Você pode seguir o procedimento descrito em Definindo componentes do instalador.
  • O instalador rastreia cada componente pelo respetivo GUID do componente especificado na tabela Component. É essencial para o funcionamento do mecanismo de contagem de referências do Windows Installer que o GUID do componente esteja correto. Siga as diretrizes em Alterando o código do componente.
  • Se o seu pacote deve 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 podem 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 arquivos ao substituindo 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 compara a versão, a data e o idioma dos dois arquivos principais e usa 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 usam 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 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 Criação de um pacote grande.

Se você usa ações personalizadas, siga 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 aplicações. Os desenvolvedores devem procurar confiar nas ações padrão tanto quanto possível, em vez de criar as 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 Usando ações personalizadas.
  • Siga as diretrizes para assegurar ações personalizadas. As ações personalizadas que usam informações confidenciais não devem gravar essas informações no log. Para obter informações, consulte Custom Action Security.
  • As Ações Personalizadas não devem tentar definir um ponto de entrada de Restauração do Sistema a partir de uma ação personalizada. Para obter informações, consulte Definir um ponto de restauração a partir de uma Ação Personalizada.
  • Retorne mensagens de erro de ações personalizadas e escreva-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 Devolver 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 do 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 ficheiro executável ou uma biblioteca de ligação dinâmica . Limite o uso de ações personalizadas com base em scripts a operações de instalação simples.
  • Torne os detalhes do que sua ação personalizada faz com o sistema facilmente detetá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 a partir dessa 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. Ações personalizadas que exigem uma interface do usuário podem usar a função MsiProcessMessage em vez disso. Consulte como enviar mensagens para o Windows Installer usando o MsiProcessMessage.
  • As ações personalizadas não devem usar nenhuma das funções listadas na página: Funções não destinadas a 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 a propriedade TerminalServer.
  • 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 as 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 registro em 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 a Sintaxe de Instrução Condicional para garantir que o 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 como esperado ao desinstalando ações personalizadas. Para obter informações, consulte Ações de Condicionamento para Executar 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. Todas as ações personalizadas que exigem privilégios elevados devem incluir o msidbCustomActionTypeInScript e msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options 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.

Caso utilize assemblies, siga as boas práticas de montagem.

Se o seu pacote usa software assemblies, siga as diretrizes para Adicionando assemblies a um pacote, Atualizando assembliese Instalando e removendo assemblies.

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

de Instalações Simultâneas, também chamado de Instalações Aninhadas, instalam outro pacote do Windows Installer durante uma instalação em execução no momento. A utilização de instalações simultâneas não é uma boa prática porque são de difícil manutenção para os clientes. A aplicação de patches e a atualização podem não funcionar com instalações simultâneas. A alternativa recomendada ao uso de instalações simultâneas é, em vez disso, 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, as 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/Remover Programas no Painel de Controlo.

Mantenha os nomes e códigos de pacotes 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 seu arquivo .msi um nome amigável que permita ao usuário identificar o conteúdo do pacote do Windows Installer.
  • O código de 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 Código do Produto e Alterando o Código do Produto. Alterar o nome do arquivo de .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 de pacote é o identificador primário usado pelo instalador para procurar e validar o pacote correto para uma determinada instalação. Nenhum arquivo .msi não idêntico 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 Information Stream.
  • Observe que as letras no código do produto e no código do pacote GUIDs devem ser 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 auto-registro porque as rotinas de auto-registro tendem a ocultar informações críticas de configuração. Para obter uma lista das razões para evitar a autoinscrição, consulte a tabela de Autoregisto .
  • Os autores do pacote de instalação são fortemente desaconselhados a usar a tabela TypeLib. Em vez de usar a tabela TypeLib, registe bibliotecas de tipos usando a tabela de registo . Se uma instalação usando a tabela TypeLib falhar e precisar ser revertida, a reversão não poderá 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 a sua aplicação forneça a opção de ser instalada com o nível de interface de utilizador definido para 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 de informações coletadas da interação do usuário com caixas de diálogo. Estas informações não estão disponíveis durante uma instalação silenciosa.
  • Não reinicie automaticamente o computador do utilizador 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 configurada, os aplicativos que não forem distribuídos pelo administrador serão instalados usando os privilégios do usuário, e somente os aplicativos geridos obterão privilégios elevados. A definição desta 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 deelevadose acessar locais seguros no computador. É uma boa prática usar outro método que não a política AlwaysInstallElevated ao Instalar um pacote com privilégios elevados para utilizadores sem direitos de administrador ou corrigir Per-User aplicações geridas.

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 aplicações. Quando essa política é 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 de outros produtos é bloqueada, 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 fonte original do pacote do Windows Installer pode ser necessária para instalar, 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 contendo as fontes necessárias. É uma boa prática para garantir que o instalador tem as fontes que precisa sem ter que avisar o usuário.

  • Use Assinaturas Digitais e Arquivos de Gabinete Externos para garantir que as fontes originais a serem usadas pelo instalador estejam 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 uma partilha DFS (Sistema de Ficheiros Distribuídos) como caminho de origem.
  • Use a API do Windows Installer para recuperar e modificar informações da lista de fontes 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 Installer Object, Product Objecte Patch Object para recuperar e modificar informações da lista de fontes para aplicativos e patches do Windows Installer.
  • Aderir aos pontos listados em Impedindo que um patch exija acesso à fonte de instalação original pontos para minimizar a possibilidade de que seu patch exija acesso às fontes 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 registro detalhado no computador do usuário ao solucionar problemas de implantação.

Registo do Windows Installer inclui uma opção de registo detalhado que pode ser ativada num computador de um utilizador. 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 registo detalhado no computador do utilizador usando as Opções de Linha de Comando , a propriedade MsiLogging , a política de registo , MsiEnableLog e o método EnableLog .
  • Um recurso muito útil para interpretar arquivos de log do Windows Installer é Wilogutl.exe. Esta ferramenta auxilia a análise de arquivos de log e exibe soluções sugeridas para erros que são encontrados em um arquivo de log.
  • A opção de registro detalhado deve ser usada apenas para fins de solução de problemas e não deve ser deixada ativada porque 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 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 estará 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 Adicionando e removendo um aplicativo e não deixando vestígios nodo 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.
  • 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 por utilizador ou 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 o implantam 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.

  • Considere os tipos de atualizações que você espera usar para fazer a manutenção de seu aplicativo no futuro. O Windows Installer fornece três tipos de atualizações: Small Update, Minor Upgradee Major Upgrades. As diferenças entre estes são descritas no tópico Patching and Upgrades.
  • Antes de enviar seu aplicativo, teste se ele funciona conforme o esperado após a manutenção com cada tipo de atualização.

Reduza a dependência de 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.

Não distribua módulos de mesclagem inutilizáveis.

As aplicações não deverão depender dos módulos de mesclagem para a instalação do componente se o proprietário do módulo de mesclagem for diferente do proprietário da aplicação. 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 numa rede uma instalação administrativa do pacote original do Windows Installer da sua aplicação para permitir que os membros de um grupo de trabalho instalem a aplicação. Os usuários dessa imagem administrativa devem então aplicar atualizações à instância local do aplicativo localizada em seu computador. Isso mantém os usuários em sincronização 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ário para os usuários obterem 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 conseguem de instalação sob demanda e reparar aplicativos de uma instalação administrativa atualizada até que eles 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 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 não instalá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, em seguida, 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 corrigindo uma imagem administrativa.

Registre 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 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 os exemplos fornecidos em Patching Per-User Managed Applications.
  • Ao executar o Windows Installer versão 4.0 no Windows Vista, também pode usar o Patching do Controlo de Conta de Utilizador (UAC) para permitir que os autores das instalações do Windows Installer identifiquem patches assinados digitalmente que podem ser aplicados no futuro por utilizadores não administrativos. 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 a correção de privilégios mínimos não foi desativada configurando a propriedade MSIDISABLELUAPATCHING ou a política DisableLUAPatching.

Use a tabela MsiPatchSequence para sequenciar correções.

Inclua uma Tabela MsiPatchSequence no 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 aplicativos de patch. Utilize as diretrizes descritas no documento técnico Sequenciamento de Correções no Windows Installer versão 3.0 para definir famílias de correções.

  • 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 oferece flexibilidade suficiente para sequenciar atualizações de software. 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 aplicação de vários patches para aplicar patches na ordem em que foram emitidos.
  • Use o PatchSequence Table no Patchwiz.dll para gerar as informações no MsiPatchSequence Table. A versão do PATCHWIZ.DLL lançada com o Windows Installer 3.0 pode gerar automaticamente informações de sequenciamento de patches. Para obter mais informações sobre como adicionar um novo patch, consulte Geração de Informações sobre a Sequência de Patches. Para obter mais informações sobre cenários de sequenciamento de patches, consulte o whitepaper: Patch Sequencing in Windows Installer version 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 de Instalação Administrativa, de Instalação de Reversão e de Instalação por Demanda. Tente todos os métodos possíveis de instalação, incluindo clicar no arquivo .msi, opções de linha de comandoe instalar a partir do painel de controle. Teste se o pacote pode ser instalado por usuários em todos os contextos de privilégio possíveis. Tente instalar o pacote depois de ter sido implantado por todos os métodos possíveis. Habilite o registo do Windows Installer para cada teste e resolva todos os erros encontrados no registo do instalador e no registo 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 de que a interface do usuário funcione como esperado para diferentes resoluções de tela e tamanhos de fonte.
  • Testes de manutenção e reparação - Teste se o pacote consegue gerir Correção e Atualizações fornecidos por uma Atualização Pequena, Atualização Menore Atualização Maior. 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 de 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.

Efectue a validação do pacote num novo ou revisto pacote 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.

Autorize 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 a sua aplicação use o tipo PMSIHANDLE porque o instalador fecha objetos PMSIHANDLE à medida que saem do escopo, enquanto a sua aplicação 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);

Altere-o para:

PMSIHANDLE hRec = MsiCreateRecord(3);

 

 

  • Last updated on